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S I R: 



Pursuant to 37 C.F.R. §41.37, Appellants herewith submit their main brief in 
support of the appeal of the above-referenced application. 
REAL PARTY IN INTEREST: 

The real party in interest is the assignee of the present application, Siemens 

Aktiengesellschaft, a German corporation. 
RELATED APPEALS AND INTERFERENCES: 

There are no related appeals and no related interferences. 
STATUS OF CLAIMS: 

Claims 1-22 are the subject of the present appeal, and constitute all pending 
claims of the application. No claims were added or cancelled during prosecution 
before the Examiner. 
STATUS OF AMENDMENTS: 

The present appeal is being taken from the Office Action dated January 31, 
2007, which was not a Final Rejection, but which was the second time the claims on 
appeal have been rejected. In that Office Action, claim 1 was objected to because 
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the Examiner stated the term "said examination images" in line 5 lacked sufficient 
antecedent basis, Amendment "D ,f was filed simultaneously with the present Notice 
of Appeal and Appeal Brief, wherein claim 1 was amended to overcome this 
objection. This objection was also the subject of an interview conducted with the 
Examiner, wherein it was agreed that amending claim 1 in this manner would 
overcome this objection, Accordingly, Appellants assume that this objection will be 
overcome, and need not be addressed herein. Since Amendment "D" was filed 
simultaneously with the present Appeal Brief, the status of Amendment "D" is not 
known at this time, but Appellants see no reason why Amendment "D" should not be 
entered. 

SUMMARY OF CLAIMED SUBJECT MATTER: 

The claims on appeal concern a medical system architecture of the type 
initially described wherein cail system linked into the medical workflow for the 
transmission of messages, for example as datafifes, is allocated to at least one of the 
workstations. The user of a medical workstation, for example a modality, can send 
digital messages to an expert in an electronic manner proceeding from the console 
of the workstation. The medical modalities can be, for example, an MR, CT, 
ultrasound, X-ray or angiography device, a nuclear camera, supervision monitor, 
diagnostic workstation or irradiation apparatus. An automated expert cal! system to 
a mobile communication device proceeding from a workstation is thus obtained that 
is integrated into the work and data context of the medical workstation. Due to the 
combination of the workstation with a call system, a completely new application 
scenario arises wherein the radiologist — as an expert — is available by retrieval 
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This application scenario has not been realizable with the previous means (for 
example, image transfer to workstations), (p,2 3 1.22 -p,3, 1.11) 

Claim 1 (the only independent claim of the application) is set forth below, with 
exemplary citations to the specification and drawings for the claim elements. 

1 . A medical system architecture comprising: 

an imaging modality for acquiring medical examination images of an 
examination subject (any of CT unit 1 , MR unit 2, DSA unit 3, x-ray unit 
4, Fig. 1, L3-8); 

a workstation selected from the group of workstations consisting of 
workstations for acquiring said examination images (any of 
workstations 5-8; Fig. 1, p. 5, 1.8-11), workstations for sending said 
examination image (also any of workstations 5-8) p. 5, 1.12-17), and 
workstations for receiving said examination images (viewing 
workstations 11; Fig. 1, p. 5, 1.18-24); 

a system connected to said workstation for transmitting said medicai 
examination images to at least one location remote from said 
workstation (communication network 9; Fig. 1, p. 5, L12-14); and 

a calf system allocated to said workstation for transmitting messages together 
with data representing said medical examination images to a remote 
location (Fig. 2, p.6, L 17-23 and Fig. 3, p.7, L3 -10). 
GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL: 

The following issues are presented in the present Appeal: 

Whether the subject matter of claims 1-14 is anticipated under 35 U.S.C. 
§1 02(e) by United States Patent No. 6,321,113 (Parker et aL); 
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Whether the subject matter of ciaim 15 would have been obvious to a person 
of ordinary skill in the field of medical system architecture design under the 
provisions of 35 U.S.C. §1 03(a) based on the teachings of Parker et ai. in view of 
United States Patent No. 6,629,131 (Choi); 

Whether the subject matter of claims 16-19 and 22 would have been obvious 
to a person of ordinary skill in the field of medical system architecture design under 
the provisions of 35 U.S.C. §1 03(a) based on the teachings of Parker et al., further in 
view of "Official Notice" of various types of communication software and 
components; 

Whether the subject matter of claim 20 would have been obvious to a person 
of ordinary skill in the field of medicai system architecture design under the 
provisions of 35 U.S.C. § 103(a) based on the teachings of Parker et at., further in 
view of United States Patent No. 6,304,898 (Shiigi); and 

Whether the subject matter of claim 21 would have been obvious to a person 
of ordinary skill in the field of medical system architecture design under the 
provisions of 35 U.S.C. §1 03(a) based on the teachings of Parker et aL, further in 
view of United States Patent No, 6,829,478 (Layton et al.)- 
ARGUMENT; 

Rejection of Claims 1-14 Under 35 U.S.G. §1 02(e) as being Anticipated by 
Parker et at 

Claim 1 claims a medical system architecture wherein examination images of 
an examination subject are acquired with an imaging modality, and are supplied to a 
workstation that is connected to a system for transmitting the examination images to 
at ieast one location that is remote from the workstation. The medical system 
architecture of claim 1 also requires a call system allocated to the workstation for 
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transmitting messages together with data representing the medical images to a 
remote location. 

Appellant's position with regard to ail rejections based on the Parker et aL 
reference {Exhibit D) is that there is no disclosure in the Parker et aL reference 
describing the generation or transmission of images in general, nor any disclosure of 
the transmission of medical images or examination images (both terms being used in 
claim 1, as noted above). The Parker et a!, reference is exclusively concerned with 
the generation and transmission of text data, possibly combined with a 
representation of an electrical signal, such as an ECG- Appellants argued that an 
ECG is simply a trace or a curve, representing a single eJectrical signal, and does 
not represent a medicai examination image, as that term is commonly understood by 
those of ordinary skill in the field of medical imaging. 

Numerous standard texts and dictionaries support the position of the 
Appellants that the term "medical examination image" is not considered by those of 
ordinary skill in the field of medicai imaging to encompass an ECG, 

Attached hereto as Exhibit "A" is an excerpt from the McGraw-Hill Dictionary 
of Scientific and Technical Terms, providing a definition of medical imaging as the 
production of visual representations of body parts, tissues or organs, This definition 
clearly does not encompass an ECG, and electrocardiography is not listed as being 
among the general categories of medical imaging provided in that definition, 

Exhibit is an excerpt from a standard medical text (Foundations of Medical 
Imaging), and in the introduction, that provides an overview of all types of medical 
imaging that will treated in the text, a definition is provided in the third full paragraph 
at page 4 5 stating that modern or contemporary medicai imaging is a two-part 
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process: (1) the collection of data concerning the interaction of some form of 
radiation with tissue, and (2) the transformation of these data into an image (or a set 
of images) using specific mathematical methods and computational tools. Clearly an 
ECG is simply a measurement of an electrical signal, and does not involve the 
interaction of radiation with a subject fn this regard, it is no different than a curve 
representing a measurement of blood pressure, temperature, etc., and thus falls into 
the category of ''sensing" rather than "imaging." An excerpt from another standard 
text (Principles of Medical imaging') is attached hereto as "Exhibit "C'\ in the 
Preface to that textbook, the various categories of medical imaging (imaging 
modalities) are listed, and clearly ECG is not included. 

Appellants respectfully submit that the exhibits hereto are highly 
representative of the meaning that those of ordinary skill in the field of medical 
imaging ascribe to the term "medical examination images," and they clearly 
demonstrate that those of ordinary skill do not ordinarily consider an ECG to fall 
within that definition. 

In the context of the anticipation rejection based on Parker et ai. } this is not 
simply a trivial or semantic distinction, The fact that the Parker et al reference does 
not provide any disclosure whatsoever with regard to acquiring or transmitting 
medical examination images, as that term is commonly understood by those of 
ordinary skill in the field of medical imaging, is sufficient to overcome the anticipation 
rejection of claims 1-14 based on the Parker et aL reference, since the Parker et al. 
reference does not disclose all of the elements of claim 1 as arranged and operating 
in that claim. Claims 2-14 add further structure to the novel combination of claim 1, 
and therefore are not anticipated by Parker et al. for the same reasons. 
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Rejection of Claim 15 Under 35 U«S»C» §1 03(a) Based on Parker et aL and Choi. 

As to all of the rejections under 35 U.S.C. §1 03(a) wherein Parker et aL is 
relied upon as the primary reference, in combination with respective secondary 
references or "official notice," the distinction between a "medical examination image 55 
and an ECG is relevant because, in order to substantiate a rejection under 35 U.S.C. 
§1 03(a) based on a modification of the Parker et aL reference, the Examiner must 
provide evidentiary support for the position that it would have been obvious to a 
person of ordinary skill in the field of medical imaging to make use of the teachings 
of Parker et aL, which are exclusively directed to the generation and transmission of 
an ECG, for the purpose of generating and transmitting true "medical examination 
images." In view of the above evidence showing that those of ordinary skill in the 
field of medical imaging do not consider an ECG to fall into the category of a 
"medical examination image," Applicants respectfully submit the Examiner cannot 
simply conclude, without proper evidentiary support, that there is no difference 
between the two, Appellants respectfully submit the Examiner has not provided the 
proper evidentiary support required by numerous decisions of the United States 
Court of Appeals for the Federal Circuit indicating a motivation, inducement or 
guidance in any of the references of record to apply the teachings of Parker et aL, 
which are exclusively disclosed in that reference in the context of ECG generation 
and transmission, to the generation and transmission of "medical examination 
images." In view of the significant differences between an ECG and a true "medical 
examination image/ 1 Appellants respectfully submit that even if a person of ordinary 
skill in the field of medical imaging had the insight to apply the ECG-based teachings 
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of Parker et aL to the field of medical imaging, this would be an insight supporting 
patentability, rather than a basis for negating patentability. 

The Federal Circuit stated in in re Lee 227 F.3d 1338, 61 USP.G. 2d 1430 
(Fed. Cir. 2002): 

"The factual inquiry whether to combine references must be thorough 
and searching. ...It must be based on objective evidence of record. 
This precedent has been reinforced in myriad decisions, and cannot be 
dispensed with/' 

Similarly, quoting C.R. Bard, Inc. v, M3 Systems, inc. 157 F.3d 1340, 1352, 

48 U,SP,Q. 2d 1225, 1232 (Fed. Cir. 1998), the Federal Circuit in Brown & 

Williamson Tobacco Court v. Philip Morris, inc., 229 F.3d 1120, 1124-1125, 56 

US.P.G. 2d 1456, 1459 (Fed. Cir. 2000} stated: 

[A] showing of a suggestion, teaching or motivation to combine the 
prior art references is an 'essential component of an obviousness 
holding'. 

In In re Dembiczak, 175 F.3d 994,999, 50 U.SPA 2d 1614, 1617 (Fed. Cir, 

1999) the Federal Circuit stated: 

Our case law makes clear that the best defense against the subtle but 
powerful attraction of a hindsight-based obviousness analysis is 
rigorous appiication of the requirement for a showing of the teaching or 
motivation to combine prior art references. 

Consistently, in In re Rouffet, 149 F.3d 1350, 1359, 47 U.S.P.Q. 2d 1453, 

1459 (Fed. Cir. 1998), the Federal Circuit stated: 

[E]ven when the level of skill in the art is high, the Board must identify 
specifically the principle, known to one of ordinary skill in the art, that 
suggests the claimed combination. In other words, the Board must 
explain the reasons one of ordinary skill in the art would have been 
motivated to select the references and to combine them to render the 
claimed invention obvious. 

in Winner international Royalty Corp. v. Wang, 200 F.3d 1340, 1348-1349, 53 
U.S.P.Q. 2d 1580, 1586 (Fed. Cir. 2000), the Federal Circuit stated: 
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Although a reference need not expressly teach that the disclosure 
contained therein should be combined with another, ... the showing of 
combinability, in whatever form, must nevertheless be clear and 
particular 

Lastly, in Crown Operations International, Ltd. v. Solutia, Inc., 289 F.3d 1367, 

1376, 62 LLSP.Q. 2d 1917 (Fed. Cir 2002), the Federal Circuit stated: 

There must be a teaching or suggestion within the prior art, within the 
nature of the problem to be solved, or within the genera! knowledge of 
a person of ordinary skill in the fieid of the invention, to look to 
particular sources, to select particular elements, and to combine them 
as combined by the inventor. 

For these reasons, even if the Examiner's statements regarding the individual 
teachings of the Choi reference (Exhibit "E") are accurate, Appellants respectfully 
submit the Examiner has not satisfied the aforementioned rigorous evidentiary 
standards for the Examiner's interpretation of the term "medical image" in claim 1, 
nor as to the alleged guidance, based on teachings in the references themselves, for 
combining the references in the manner proposed by the Examiner. 

Claim 15, therefore, would not have been obvious to a person of ordinary skill 
in the field of medical system architecture design under the provisions of 35 U.S.C. 
§1 03(a), based on the teachings of Parker et al. and Choi. 

Rejection of Claims 16-19 and 22 Under 35 U.S.C. §103(a) as being 
Unpatentable over Parker et aL in View of "Official Notice" 

With regard to ciaim 16, the Examiner took Office Notice that the concept and 

advantages of using Corba technology are well known, and the Examiner took the 

same position with regard to Official Notice with respect to the use of instant 

messaging technology in claim 17, Java Enterprise Beans technology in ciaim 18 f 

the use of Java Applet in a browser with regard to claim 19 and the use of a beeper 

with regard to claim 22. For brief descriptions of Corba and Java Beans, the 

Examiner cited Microsoft Computer Dictionary, 5 th Ed. (Exhibit "F). 
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For the same reasons discussed above in connection with the rejection based 

on Parker et al. and Choi, Appellants respectfully submit that even if the Examiner's 

conclusions regarding the various items for which Official Notice has been taken are 

correct, the references still do not provide the rigorous evidentiary support as to 

teachings that would guide a person of ordinary skill in the medical architecture 

technology to combine the known information with the subject matter of claim 1 , 

Rejection of Claim 20 under 35 U.S.C. §103(a) as Unpatentable over Parker et 
al. in view of Shiigi 

The Examiner has relied on the Shiigi reference (Exhibit "G") as teaching a 
WAP phone, which the Examiner acknowledges is not taught in the Parker et al. 
reference. Appellants acknowledge that the Shiigi reference provides such a 
teaching, however, for the same reasons noted above with regard to the other 
rejections under 35 U.S.C. §103(3), Appellants respectfully submit the Examiner has 
failed to satisfy the high standard of evidence required to support the position that 
either of the Parker et al. or Shiigi references provides teachings, motivations, 
inducements or guidance to a person of ordinary skill in the field of medical system 
architecture design, so as to justify a conclusion that it would have been obvious to 
such a person of ordinary skill to modify the Parker et al. reference in accordance 
with the disclosure of the Shiigi reference, This is particularly true, as with the other 
rejections under 35 LLS.C, §1 03(a), in view of the discussion above regarding the 
term "medical image" in claim 1 and the lack of a teaching thereof in the Parker et al 
reference. 
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Rejection of Claim 21 under 35 U.S.C. §103{a) as Being Unpatentable over 
Parker et aL in view of Lavton et aL 

The Examiner relied on the Layton et aL reference (Exhibit "H") as teaching 

an SMS phone, which the Examiner acknowledged is not disclosed in the Parker et 

al. reference. Appellants acknowledge that the Layton et al. reference provides such 

a teaching, but for the reasons noted above with regard to the other rejections under 

35 U.S.C, §1 03(a), Appellants respectfully submit the Examiner has failed to satisfy 

the high standard of evidence required to support the position that either of the 

Parker et al or Layton et al. references provide teachings, motivations, inducements 

or guidance to a person of ordinary skill in the field of medical system architecture 

design, so as to justify a conclusion that it would have been obvious to a person of 

ordinary skill to modify the Parker et aL reference in accordance with the teachings 

of the Layton et aL reference. This is particularly true, as with the other rejections 

under 35 U.S.C. §103(a) in view of the discussion above regarding the term "medical 

image" in claim 1 and the lack of a teaching thereof in the Parker et at, reference. 

CONCLUSION: 

For the foregoing reasons, Appellants respectfully submit the Examiner is in 
error in law and in fact in rejecting claims 1-22 that are of the subject of the present 
Appeal. Reversal of those rejections is therefore proper, and the same is 
respectfully requested. 
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This Appeal Brief is accompanied by a request to credit the previously-paid 
Appeal Brief filing fee to the present Appeal Brief. 

Submitted by, 

JS^-^C \A^€J^ (Reg. 28.982) 

SCHIFF, HARDIN LLP, CUSTOMER NO. 26574 
Patent Department 
6600 Sears Tower 
233 South Wacker Drive 
Chicago, Illinois 60606 
Telephone: 312/258-5790 
Attorneys for Appellants. 
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CLAIMS APPENDIX 

1 . A medical system architecture comprising: 

an imaging modality for acquiring medical examination images of an 
examination subject; 

a workstation selected from the group of workstations consisting of 
workstations for acquiring said medical examination images, 
workstations for sending said examination image, and workstations for 
receiving said examination images; 

a system connected to said workstation for transmitting said medical 
examination images to at least one location remote from said 
workstation; and 

a call system allocated to said workstation for transmitting messages together 
with data representing said medical examination images to a remote 
location, 

2. A medical system architecture as claimed in claim 1 wherein said 
workstation also processes data associated with said examination images, and 
further comprising a memory connected to said system which stores said data and 
said examination images in allocated fashion. 

3. A medical system architecture as claimed in cfaim 1 wherein said call 
system allows manually modifiable entries of auxiliary information to ensue 
automatically from object types stored in a data bank. 



4. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a user front end, a communication service and a mobile 
communication device. 

5. A medical system architecture as claimed in claim 4 wherein said user 
front end is integrated in an application at said workstation. 

6. A medical system architecture as claimed in claim 4 wherein said 
communication services comprises a communication server and a communication 
system, 

7. A medical system architecture as claimed in claim 1 wherein said call 
system alfows a manually modifiable entry of a message recipient to ensue 
automaticalfy in said message. 

8. A medical system architecture as claimed in cfaim 1 wherein said call 
system aflows a manually modifiable entry of a current patient, being examined with 
said modality, to ensue automatically in said message. 

9. A medical system architecture as claimed in claim 1 wherein said call 
system allows a manually modifiable entry of a current procedure being executed by 
said modality to ensue automatically in said message. 

10. A medical system architecture as claimed in claim 1 wherein said cai! 
system allows entry of an arbitrary text as specific auxiliary information in said 
message. 

11. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a mobile communication device with a display. 
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12. A medical system architecture as claimed in claim 11 wherein said call 
system includes a voice input unit at said workstation allowing a voice input to be 
transmitted to said communication device as an audio data file, and wherein said 
communication device comprises an audio transducer allowing emission of said 
voice input at said communication device, 

13. A medical system architecture as claimed in claim 1 wherein said 
workstation has a monitor on which said medical examination images are displayed, 
and wherein said call system is connected to said workstation to cause a 
communication window to be overlaid on said examination images at said monitor 

14. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a mobile communication device with a display and an information 
return channel from said communication device to said workstation aliowing 
information to be transmitted from said communication device to said workstation. 

15. A medical system architecture as claimed in claim 14 wherein said 
communication device transmits a confirmation of receipt of said message to said 
workstation after said message has been read at said communication device. 

16. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a user front end f a communication service and a mobile 
communication device, and wherein said workstation communicates with said 
communication service via Corba technology. 
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17. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a user front end, a communication service and a mobile 
communication device, and wherein said workstation communicates with said 
communication service via Instant Messaging technology. 

18. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a user front end, a communication service and a mobile 
communication device, and wherein said workstation communicates with said 
communication service via Java Enterprise Beans technology. 

19. A medical system architecture as claimed in claim 1 wherein said cal! 
system comprises a user front end, a communication service and a mobile 
communication device, and wherein said user front end comprises a Java applet in a 
browser. 

20. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a user front end, a communication service and a WAP cell phone. 

21. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a user front end, a communication service and a SMS cell phone. 

22. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a user front end, a communication service and a beeper with a 
display. 
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RELATED APPEALS AND INTERFERENCES 

None. 
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EVIDENCE APPENDIX 



th 



Exhibit A; McGraw-Hill Dictionary of Scientific and Technical Terms, 5 
Ed,, Parker (Editor in Chief (1994)) - submitted with January 17, 
2006 Amendment that was entered upon the filing of the RCE 
on May 2, 2006, 

Exhibit B: "Foundations of Medical imaging," Cho et ai. (1993) pages 3-5 - 

submitted with January 17, 2006 Amendment that was entered 

upon the filing of the RCE on May 2, 2006, 
Exhibit C; "Principles of Medical Imaging," Shung et al. (1992) pages xiii - 

xiv - submitted with January 17, 2006 Amendment that was 

entered upon the filing of the RCE on May 2, 2006. 
Exhibit D: United States Patent No. 6,321,113 (Parker et al.) - cited in the 

Final Rejection dated June 26, 2006. 
Exhibit E: United States Patent No. 6,629,131 (Choi) - cited in the Final 

Rejection dated June 26, 2006. 
Exhibit F: Microsoft Computer Dictionary, 5 th Ed, - cited in the Finai 

Rejection dated June 26, 2006. 
Exhibit G: United States Patent No. 6,304,898 (Shiigi) - cited in the Final 

Rejection dated June 26, 2006. 
Exhibit H: United States Patent No. 6,829,478 (Layton et al.) - cited in the 

Final Rejection dated June 26, 2006. 
Exhibit I: Request for Continued Examination (RCE) Transmittal - filed 

May 2, 2006. 

Exhibit J: Figs. 1-3 - filed as part of the original application on November 
19, 2001. 
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ineconium ileus 



medicinal 0(^5; medU 



ECO PTE BA 




fiy (Panorpa), 



In the fetal intestine, becoming the first fecal discharge of the 
newborn,- ( m^'kctie-am \ 

meconium ileus . [med] intestinal obstruction in the newborn 
with cystic fibrosis due to trypsin deficiency, ( ma'kc-ne-am 
'iPS^s } 

Mecoptera [ikv zoo] The scorpion flies, a small order of 
insects; adults are distinguished by the peculiar prolongation of 
the head into a beak, which bears chewing mouth parts. 
[ me'kaptsrra } . 

mecystasls [phvsio] Increase in muscle length with main- 
tenance of the original degree of tension. \ me'sis-te-sss } 

media [hiSTOL] The middle, muscular layer in the wail of a 
vein, artery* or lymph vessel. { 'me*d£*a } 

media conversion (comput sci) The transfer of data from 
one storage type (such as punched cards) to another storage type 
(such as magnetic tape). \ 'me*de-3 kan.varzhan j 

media conversion buffer [comput sci] Large storage area, 
such as a drum, on which data may be stored at low speed during 
nonexecution time, to be later transferred at high speed into core 
memory during execution time. { 'me-de-a ka^varzhim ,baf* 
ar f 

mediad [anatJ Toward the median line or plane of the body 
or of a part of the body. { f rtie*de f ad } 

medial [anatJ 1 . Being internal as opposed to external (lat- 
eral), 2. Toward the midline of the body, [set tech] Located 
in the middle. ( 'me-de-al ] 

medial arteriosclerosis [med} Calcification of the tunica 
media of small and medium-sized muscular arteries. Also 
known as medial calcinosis; Monckeberg's arteriosclerosis, 
{ 'mWc^al .artire'O-skb'ro-sas I 

medial calcinosis^** medial arteriosclerosis. { 'me*de*sl ,kal- 
ss'nd-sas J 

medial lemniscus [anat] A lemniscus arising m the nucleus 
gracilis and nucleus cuneatus of the brain, crossing immediately 
as internal arcuate fibers, and terminating in the posterolateral 
ventral nucleus of the thalamus- [ 'me*dg'S>l lem'nis'kas } 

medial moraine ]oeol] 1 . An elongate moraine carried in or 
upon the middle of a glacier and parallel to its sides. 2. A 
moraine formed by glacial abrasion of a rocky protuberance 
near the middle of a glacier. { J me-de^l ms'ran } 

medial necrosis [med] Death of cells in the tunica media of 
arteries. Also known as medionecrosis. { 'me*de-a] ne'kro* 
s^s | 

media migration [chem eng] Carryover of fibers or other 
filter material by liquid effluent from a filter unit { l me-d£*» 
m! , gra*sh3n } 

median [math] 1 . Any line in a mangle which joins a vertex 
io the midpoint of the opposite side. 2, The line that joins the 
midpoints of the nonparalie! sides of a trapezoid. Also known 
as midline. |sci tech] Located in the middle. [ST at] An 
average of a series of quantities or values; specifically, the quan- 
tity or value of that item which is so positioned in the series, 
when arranged in order of numerical quantity or value, that there 
are an equal number of items of greater magnitude and lesser 
magnitude. ■ [ + me-de-;m ] 

median effective dose See effective dose 50. { me-de-sn i f ek- 

liv 'dos } ^ . t Fn 

median infective dose See infective dose 50, I me-de^n 

in'Fek'tiv *dos } 

median lethal dose See lethal dose 50. | l me-de-3tt ieth-al 

'dos 1 . , 

median iethal time {microbig] The penod of tune required 
for 50% of a large group of organisms to die following a specific 
dose of an injurious agent, such as a drug or radiation. { *me- 
da*:m 'teth-sl ,tim ) , 

median mass [geolJ A less disturbed structural block m the 
middle of an orogenic belt, bordered on boEh sides by orogenic 
structure, thrust away from it- Also known as betwixt moun- 
tains; Zwischengebh-ge. ( 'me-de-sn 'mas j 

median maxillary cyst [med] Cystic dilation of embryonal 
inclusions in the incisive fossa or between the roots of the central 
incisors. Also known as nasopalatine cyst. 1 *me>de>3n 'mak- 
sa.ler-e t sist } . * , * 

median nasal process [embryo] The region below the f ron- 
xonasal sulcus between the olfactory sacs; forms the bridge and 
mobile septum of the nose and various pans of the upper jaw 
and lip. i 'me-de-an 'na2*3i *pra-$£s ] 

median nerve test [med] A test for loss of function of the 
median nerve by having the patient abduct the thumb at right 
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angles to the paim with fingertips in contact and forrning,:^^ 
pyramid. [ f me*de*sn 'narv ,test } ; : 

median particle diameter [oeol] The middlemost particl^r: 
diameter of a rock or sediment, larger than 50% of the diaineti^lg^ 
in the distribution and smaller than die other 50%. [ i «We3|Vj 
an ^ard-a-kal di.am^d-ar i :M | 

median point [math] The point at which all three median*^ ^ 
of a triangle intersect. { 'med'e-aii , point J 

median strip [civ eng] A paved or planted section dividing^: | 
a highway into lanes according to direction of travel. { 'rn^fej 
de-an 'strip } , 1 

mediastinals [med] Infiammation of the rrtediasumm^JJ ^ 
[ ,me*de,as-t3'nid-as } 

mediastinum [an at] 1 . A partition separating adjacent pans, y ■ 
2, The space in the middle of the chest between the two pleiirae>£-.T 
[ ,me-de-3'sti-n3m j t . -f 7;$ 

medical bacteriology [med] A branch of medical microbe ^ j : 
ology that deals with the study of bacteria which affect human 
health, especially those which produce disease. { 'med^ksi 
bak,tir**Sl-a-je \ 4 

medical chemicsi engineering [chemeho] Trie application 
of chemical engineering to medicine, frequently involving mass * 
transport and separation processes, especially at the molecular- 
level. { 'med-srksl *kenv3-kal .en-ja'niriTj 1 

medical climatology (meo] The study of the relation be- 
tween climate and disease. ( *rned-3'k3l ^-ms'tal-yje } ; 

medical electronics [euECXR] A branch of electronics in 
which electronic instruments and equipment are used for such, 
medical applications as diagnosis, therapy, research, anesthesia 
control* cardiac control, and surgery. [ 'med^-kal Uek'trfn* 
iks | 

medical entomology [med] The study of insects that arc 

vectors for diseases and parasitic infestations in humans and ... 

domestic animals. { 'merf^-kst ,enna l ma1*3vg ) 
medical ethics [med] Principles and moral values of proper 

medical conduct. [ 'med-a-k^reth-iks } 
medical examiner [med] A professionally qualified physic 

cian duly authorized and charged by a governmental unit to 

determine facts concerning causes of death, particularly deaths 

not occurring under natural circumstances, and to testify thereto 

in courts of law. { l med^*kal ig'zam^-nsr ) r 
medical frequency bands [commun] A collection of radio 

frequency bands allocated to medical equipment in the United ^ 

States. I 'med^-kal 'fre-kwwse ,banz } 
medical genetics [gen] A field of human genetics concerned 

with the relationship between heredity and disease. \ 'med-a- 

k^l ja'ned-iks } 

medical geography [med] The study of the relation between 
geographic factors and disease. 1 'med-s-ksl je^ag-ra-fE } -} 

medical history [med] An account of a patient's past and : 
present state of health obtained from the patient or relatives. 
{ 'med-^kal 'hisnre 1 • 

medical imaging [med] The production of visual represen- 
tations of body parts, tissues, or organs, for use in clinical _r 
diagnosis; encompasses x-ray methods, magnetic resonance - 
imaging, single -phot on -emission and positron-emission . 
lomography, and ultrasound, f 'med-o^kai im-ij-irj ) 

medical microbiology [med] The study of microorganisms 
which affect human health. \ 'med-a-k^ JmT-krS-brSi-a-je 1 

medical mycology [med] A branch of medical microbiology ^ 
that deals with fungi that are pathogenic to humans, i 'med^ ~ :j 
ksl mrical-s*je } - ^ > 

medical parasitology [med] A branch of medical microbi- 
ology which deals wilh the relationship becween humans and . ; 
those animals which live in or on them, j 'med-^ksl .par*".:} 
si'ial'S-je j 

medical protozoology [med] A branch of medical micro- 
biology thai deals with the study of Protozoa which are parasite* ; 
of humans. I ^med-^ksi ,pro-d6*x6*aI^je } 

medical radiography [med] Hie use of x-rays to produce 
photographic images for visualizing internal anatomy as an aid ; 
in diagnosis. \ 'med-g-kal jrad^-'ag-ra-fe } .j 

medication [med] 1, A medicinal substance, 2, Treatmew 
by or administration of a medicine. I ,med*3'ka*sh3n [ \ 

medicinal [med] Of, pertaining to. or having the nature of -j 
medicine, \ ms'dis-^n-al ] 

medicinal oil [mater] A highly refined, colorless, tasteie^ 
m $ odorless petroleum oil used medicinaily as an internal lu- 
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INTRODUCTION 



The study of medical imaging is concerned with the interaction of all forms of 
radiation with tissue and the development of appropriate technology to 
extract clinically useful information from observations of this interaction- 
Such information is usually displayed in an image format. Medical images can 
be as simple as a projection or shadow image — as first produced by Rontgen 
nearly 100 years ago and utilized today as a simple chest X-ray — or as 
complicated as a computer reconstructed image — as produced by computer- 
r/ed tomography (CT) using X-rays or by magnetic resonance imaging (MR J) 
using intense magnetic fields. 

Although, strictly speaking, medical imaging began in 1895 with Rontgen's 
discoveries of X-rays and of the ability of X-rays to visualize bones and other 
Mructures within the living body [1], contemporary medical imaging began in 
(he 1970s with the advent of computerized tomography {2, 3]. Early, or what 
we call classical, medical imaging utilizes images that are a direct manifesta- 
tion of the interaction of some form of radiation with tissue. Three examples 
will illustrate what we mean by classical imaging. First is the conventional 
X-ray procedure in which a beam of X-rays is directed through the patient 
onio a film. The developed film provides a shadow image of the patient which 
ts a direct representation of the passage of X-rays through the body. Al- 
though such images are not quantitative, they do provide some measure of 
(he attenuation of X-rays in tissue. Thus a section of soft tissue will appear 
thtrker than an equally thick section of bone, which attenuates more of the 
X-rays. It should be noted that even with current technological developments 
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4 INTRODUCTION 

conventional X-ray imaging still represents the major imaging procedure at 
most medical facilities, 

As a second example of classical imaging, consider a conventional nuclear 
medicine procedure. Here a radioactive material is injected into the patient 
and its course followed by a detector which is moved over the patient in a 
specified manner. Although the image recorded by the detector generally has 
poor spatial resolution, its real advantage is that it provides a measure of 
physiological function from the time course of the radioisotope uptake. 
Clearly the conventional nuclear medicine image is a direct measure of the 
location and concentration of the radioactive isotope used. 

As a final example of classical imaging, consider conventional medical 
ultrasound. Here, a pulse of ultrasonic energy is propagated into the patient 
and the backscattered echo signal is recorded by the same transducer. By 
angulating or moving the transducer <or by using a transducer array) position- 
ally sequential echo signals are recorded, and a cross-sectional image of the 
subject is displayed directly on a video monitor, Ultrasound images are really 
a mapping of echo intensities and are a direct result of the interaction of the 
ultrasound pulse with tissue. 

In this text we will define modern or contemporary medical imaging 
operationally as a two-part process: <1) the collection of data concerning the 
interaction of some form of radiation with tissue, and (2) the transformation 
of these data into an image (or a set of images) using specific mathematical 
methods and computational tools. Note that our definitions for both classical 
and modem imaging are consistent with our general definition of medical 
imaging, given in the first paragraph of this chapter. Note also that modern 
imaging can be represented as a generalization of classical imaging and that 
classical imaging is simply a special case of modern imaging in which the 
image forms directly from the interaction process. Whereas classical imaging 
is direct and intuitive, modern imaging is indirect and, in many cases, counter 
intuitive. Since modern images are formed by processing, reformulating, or 
reconstructing an image from the tissue /radiation interaction data base, the 
process is often referred to as "reconstruction" and the image as a "recon- 
structed image." . 

The first device capable of producing true reconstructed images was 
developed by G. R Hounsfield [2] m 1972 at EMI in England. Hounsfield's 
X-ray computerized tomograph device was based in part on mathematical 
methods developed by A. NL Cormack [4] a decade earlieF. For their efforts 
Hounsfield and Cormack were awarded the Nobel Prize in medicine in 1979, 
Put quite simply, CT imaging is based on the mathematical formalism that 
states that if an object is viewed from a number of different angles, then a 
cross-sectional image of it can be computed (or "reconstructed")- Thus X-ray 
CT yields an image that is essentially a mapping of X-ray attenuation or 

tissue density. . , 

The introduction of X-ray CT in 1972 represents the real beginning of 
modern imaging and has altered forever our concept of imaging as merely 
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Table 1-1 3-D image reconstruction algorithms 





2-D Projection 
Reconstruction 


Parallel-Beam Mode 


2-D and 3-D 

Projection 

Reconstruction 


Fan-Beam Mode 


3-D Projection 
Reconstruction 


Parallel-Beam Mode 






1 Cone-Beam Mode 


Iterative 


Algebraic Reconstruction Technique (ART) 


Method 


Maximum Likelihood Reconstruction (MLR) or 
Expectation Maximization (EM) Reconstruction 


Fourier 


Direct Fourier Reconstruction (DFR) 


Reconstruction 


Direct Fourier Imaging (DFT) in NMR 



inking a picture. It has also led to the development of 3-D imaging and is 
making quantitative imaging a reality. The application of reconstructive 
tomography. to conventional nuclear medicine imaging has led to the develop- 
ment of two new imaging modalities; single photon emission computed 
sinography (SPECT) and positron emission tomography (FET). Similar 
applications to the laboratory technique of nuclear magnetic resonance 
i NMR) has led to magnetic resonance imaging (MRIX The CT concept is 
currently being extended to 3-D magnetoencephalography, electrical 
impedance tomography, and photon migration tomography, to name a few. 
Inherent to the development of these new imaging modalities has been the 
development of new reconstruction techniques, which are detailed in 
Table 1~L 

In this chapter we seek to provide a brief historical perspective for the 
various medical imaging modalities that are currently important. The various 
u-chniques are shown in Figs. 1-1 and 1-2 where they are characterized by the 
jnicrrogation wavelengths. A parallel sequence will be followed in the suc- 
ceeding chapters which provide more detailed discussions of the various 
imaging modalities. Although the various imaging techniques will, of neces- 
sity, be treated separately, our goal is to provide a unified approach to the 
field of medical imaging. 



1-1 THE BEGINNING WITH X-RAYS 



The history of medical imaging really began on November 8 a 1895 ? when 
Wiihefan Konrad Rontgen reported the discovery of what he called "a new 
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Preface 



The field of medicai imaging is growing at a rapid pace. Since the early 1960s, 
three new imaging modalities* namely, radionuclide imaging, ultrasound, and 
magnetic resonance imaging, have appeared and matured. Along with X-ray they 
are among the most important clinical diagnostic tools in medicine today. Ra- 
dionuclide imaging, although its resolution cannot match that of other modalities, 
uses radioactive isotopes attached to biochemically active substances to yield 
unique information about the biochemical or physiological function of the organ 
which is unattainable otherwise. Ultrasound scanners use high frequency sound 
waves to interrogate the interior of the body. They are capable of depicting 
anatomical details with excellent resolution. Ultrasound is particulary suited to 
situations where exposure to ionizing radiation is undesirable, such as in obstetri- 
cal and neonatal scanning, and to imaging structures in motion, such as heart 
valves. Magnetic resonance imaging, however, has been envisioned to be the 
most exciting of them all by far because it also uses a form of nonionizing radia- 
tion, can achieve superior resolution, and is capable of yielding physiological in- 
formation. In this period, significant progress has also been achieved in conven- 
tional X-ray radiography, Improved design or introduction of better materials in 
image intensifies, intensifying and fluoroscopic screens, and photographic films 
has enhanced the resolution to a significant degree without adding higher patient 
radiation exposure levels. It is therefore plausible to understand why conventional 
radiography is still routinely used clinically for the diagnosis of many diseases and 
is the gold standard to which newer imaging modalities are compared. 

Unquestionably, the digital revolution is the primary reason that has caused 
the medical imaging field to experience the explosive growth that we are seeing 
soday. Computer and digital technology along with advances in electronics have 
made data acquisition fast and mass data storage possible. These are the most es- 
sential ingredients for the practical realization of tomographicai reconstruction 
principles. X-ray computed tomography (CT), digital radiography, real-time ultra- 
sonic scanners, single-photon emission computed tomography (SPECT), positron 
emission tomography (PET), and magnetic resonance imaging (MRI), which 
came about after the early 1970s, are just a few well-known products of the digi- 
tal revolution in medical imaging. 

While the development of these new imaging approaches may have con- 
tributed greatly to the improvement of health care, it has also contributed to the 
rising cost of health care. A chest X-ray costs only $20-30 per procedure whereas 
a magnetic resonance scan may cost up to S1000 5 let alone the expenses associ- 
ated with acquiring and installing such a scanner. The cost- to- benefit ratio for 
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these expensive procedures in certain cases is sometimes not as clear as in otters. 
Therefore it is not unusual that the clinical efficacy and contribution of these 
modalities to patient care are being scrutinized and debated constantly by the 
medical community as well as the public. 

This book is intended to be a university textbook for a senior or first-year 
graduate level course in medical imaging offered in a biomedical engineering, 
electrical engineering, medical physics, or radiological sciences department, 
Much of the material is calculus based. However, an attempt has been made to 
minimize mathematical derivation and to place more emphasis on physical con- 
cepts, A major part of this book was derived from notes used by the authors to 
teach a graduate course in medical imaging at the Bioengineering Program of 
Pennsylvania State University since the late 1970s. This book covers all four ma- 
jor medical imaging modalities, namely, X-ray including CT and digital radiogra- 
phy, ultrasound , radionuclide imaging including SPECT and PET, and magnetic 
resonance imaging. It is divided into four chapters in which a similar format is 
used- In each chapter fundamental physics involved in a modality is given first, 
followed by a discussion on instrumentation. Then various diagnostic procedures 
are described. Finally, recent developments and biological effects of each modal- 
ity are discussed. At the end of each chapter a list of relevant references, fiirther 
reading materials, and a set of problems are given. The purpose of this textbook 
is to give students with an adequate background in mathematics and physics an 
introduction to the field of diagnostic imaging; the materials discussed should be 
more than sufficient for one semester. However, the book may also be used as the 
text for a two-semester course in medical imaging when supplemented by addi- 
tional materials or by inclusion of more mathematic detail* 

Although this book has been written as a college textbook, radiologists with 
some technical background and practicing engineers or physicists working in 
imaging industries should also find it a valuable reference in the medical imaging 
field. As a final note, it should be pointed out that there are other imaging meth- 
ods that Have been used in medicine [e*g., thermography, magnetic imaging, and 
microwave imaging (Hendee, 199.1-)]. Hiey are not included in this book primar- 
ily due to their limited utility at present. Readers who are interested in these 
modalities may refer to several books listed in the following reference section. 
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ABSTRACT 



A method and system for managing cardiac rescue events is 
disclosed, Unlike prior systems, this method and system 
uses a rescue scene computer to obtain patient and incident 
data al the rescue scene and then marry Ibat data with ECG 
rescue data and automated external defibrillator (AED) 
rescue data. All of this data is then simultaneously trans- 
mitted to a base computer al an emergency medical center 
for review. Accordingly, a reviewer at the base computer cao 
immediately review the ECG and AED performance in 
context with patient and incident data. The method and 
system includes a Windows-based single screen graphical 
user interface for entering and reviewing the data and 
particularly includes a window for viewing ECG data simul- 
taneously with entry and review of att other data available in 
the single screen user interface. Hie system and method 
comprises one or more of the following elements including 
a base computer, a portable rescue scene computer, an 
automated external defibrillator (AED), and a communica- 
tion link for linking the rescue scene computer to the base 
computer and/or the AED. The system and method further 
includes software that is programmed in the base computer 
and rescue scene computer to operate the single screen user 
interface and database. 

16 Claims, 17 Drawing Sheets 
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AUTOMATIC EXTERNAL DEFIBRILLATOR 
FIRST RES PONDER AND CLINICAL DATA 
OUTCOME MANAGEMENT SYSTEM 

RELATED APPLICATION 

This application claims tbc benefit of U.S. Provisional 
Application No, 607080,130, filed Mar. 31, 1998, incorpo- 
rated herein in its entirety by reference, 

FIELD OF THE INVENTION 

The present invention relates to medical emergency event 
management and, in particular, relates to a computer-based 
communications network and database for management of 
emergency medical events such as sudden cardiac arrest 
rescue events, 

BACKGROUND OF THE INVENTION 

Cardiac arrest, exposure to high-voltage power lines, aad 
other trauma to the body can result in ventricular fibrillation 
which is the rapid and uncoordinated contraction of the 
myocardium. The use of external defibrillators to restore the 
heartbeat to its normal pace through the application of 
electrical shock is a well-recognized and important tool in 
resuscitating patients. External defibrillation is used in emer- 
gency settings in which the patient is either unconscious or 
otherwise unable to communicate. 

Automated external defibrillators (AEDs) are used by first 
responders such as police officers, paramedics, and other 
emergency medical technicians to resuscitate cardiac arrest 
patients. The AED must be used quickly and properly by the 
first responded since the chance of successfully resuscitating 
the patient decreases approximately 10 perceni-per-minule 
following cardiac arrest. 

With the advent of emerging technologies such as AEDs, 
emergency medical systems (EMS) have greater opportuni- 
ties for saving lives. However, because of increasing health 
care costs, an elevated standard of care, and competitiveness 
in the health care provider market, EMS directors must 
improve their management of cardiac rescue events with 
AEDs. 

Unfortunately, current attempts at managing performance 
of sudden cardiac arrest rescues suffer from a lack of 
coordination and cohesiveoess that is necessary to accu- 
rately and comprehensively track and evaluate cut-of- 
hospital cardiac arrest rescues. For example, data regarding 
a cardiac rescue attempt typically arrives to the EMS_ direc- 
tor from several sources, occurring at different points in 
lime, and commoaly in different formats which must be 
integrated away from the cardiac rescue site, Moreover* 
current techniques of reviewing cardiac rescue events lack 
the appropriate data to make significant strides in improving 
the quality of out -of- hospital cardiac arrest Finally, con* 
ventional computer-based tools for integrating and review- 
ing cardiac rescue data inflexibly require separate review 
aod analysis of tbe incident, the AED and AED operator 
performance, and the ECO. 

SUMMARY OF THE INVENTION 
A method and system of the present invention manages 
cardiac rescue events. Unlike prior systems, this method and 
system uses a rescue scene computer to obtain patient and 
incident data at the rescue scene and then marry that data 
with ECG rescue data and automated eternal defibrillator 
(AED) rescue data. Ail of these data are then simultaneously 
transmitted to a base computer at an emergency medical 
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center for review. Accordingly, a reviewer at tbe base 
computer can immediately review the ECG and AED per- 
formance in context with patient and incident data. 

Tbe method and system includes a Windows®-base-d 

5 single screen graphical user interface for entering and 
reviewing the data, and particularly includes a window for 
viewing ECG data simultaneously with entry and review of 
all other data available in the single screen user interface. 
In addition, as data (e.g., ECG, patient, incident, AED, 

10 etc.) are placed in the system, these data are instantly 
registered by tbe system with corresponding NHSTA codes. 
This feature automatically readies the cardiac rescue data for 
reporting 10 national authorities. In addition, the NHSTA 
codes are embedded in the background of the active data 

25 fields to permit selective activation, deactivation, 
modification, and/or initialisation. Moreover, appropriate 
data fields are supplied to insure all data for UT^TEIN -style 
reporting is obtained to permit UTSTElN-styie reporting of 
out -of- hospital cardiac arrest. 

20 Finally^ the system and method uses open database con- 
nectivity (ODBC) to permit any desired data from a cardiac 
rescue event that are logged into other types- of systems and 
methods to be imported into the method aud system of the 
present invention. Similarly, data from the system and 

25 method of the present invention can be exported to other 
ODBC-compatible data management systems and methods 
for further review, revision, or publication. 

The system and method comprises one or more of the 

30 following elements including a base computer, a portable 
rescue scene computer, an automated external defibrillator 
(AED), and a communication link for linking the rescue 
scene computer to tbe base computer and/or the AED. The 
system and method further includes software that is pro- 

35 grammed in the base computer and rescue scene compn ter to 
operate tbe single screen user interface and database. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic illustration of a cardiac rescue event 
40 data management system and method of the present inven- 
tion. 

FIG, 2 A is a schematic representation of a rescue scene 
location screen and patient information tab window, with 
optional simultaneous ECG display, of a graphical user 
45 interface of the system and method of the present invention. 

FIG. 2B is a schematic representation of a drop-down 
table for ao incident type data field of tbe rescue scene 
local ion view screen of FIG. 2 A. 

FIG. 2C is a schematic representation of an edit window 
50 for the drop-down table of FIG, 2B showing a NHSTA code 
corresponding to the incident type data field entry. 

FIG. 3 is a schematic representation of an incident infor- 
mation tab window, with optional simultaneous ECG 
display, of a graphical user interface of tbe system and 
55 method of the present invention. 

FIG. 4 is a schematic representation of a patient vitals and 
therapy information lab window, with optional simultaneous 
ECG display, of a graphical user interface of the system and 
60 method of the present invention. 

FIGS. SA-5B are schematic represeniations of a rescue 
dispatch information tab window, with optional simulta- 
neous ECG display, of a graphical user interface of the 
system and method of the present invention. 
65 FIGS. 6A-6B are schematic representations of an auto- 
mated external defibrillator and operator performance tab 
window, with optional simultaneous ECG display, of a 
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graphical user interface of the system and method of the 
present invention, 

FIGS. 7A-7E are schematic representations of a patient 
outcome tab window, with optional simultaneous BCG 
display, of a graphical user interface of the system and 
method of the present invention. 

FIG- 8 is a schematic representation of an AED and AED 
operator review tab window, with optional simultaneous 
ECG display, of a graphical user interface of the system and 
method of the present invention. 

FIG. 9 is a schematic representation of a reviewer Dote tab 
window, with optional simultaneous ECG display, of a 
graphical user interface of the system and method of the 
present invention. 

FIG. 10 is a schematic representation of a report of the 
system and method of the present invention for reporting 
UT3TEJN data od cardiac arrest incidents. 

FIG. 11 is a schematic representation of an AED deploy- 
men! tool window of the method and system of the present 
invention. 

RG. 12 is a schematic representation of an AED training 
tool window of the method and system of the present 
invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

A method and system for managing cardiac rescues of the 
present invention is schematically shown in FIG. 1 at 20. 
System 20 includes AED 22, AED data card 24, and rescue 
scene computer 26, all locatable at cardiac rescue scene 28. 
System 20 further includes land line communication link 30 
or wireless link 32 and base computer 34 at database 
management or emergency medical center 36. 

Both rescue scene computer 26 and base computer 34 
further include display 38 with graphical user interface 40 
(ie., view screen) and input means 42 such as a keyboard for 
entering data inio the view screen of the user interface. AED 
22 further includes a cable 43 for communicating with 
rescue scene computer 26. 

AED 22 preferably includes an AED such as the one 
disclosed in Olson, et. al, VS. Pat. No. 5,645,571, tilled 
AUTOMATED EXTERNAL DEFIBRILLATOR WITH 
liD ACTIVATED SELF-TEST SYSTEM, which is hereby 
Incorporated by reference in its entirety. AED 22 is capable 
of recording an ECG on a patient, and advising and deliv- 
ering an electrical shock as necessary The AED also makes 
an audio recording at the cardiac rescue scene of an opera- 
tor's or bystander's voice during the ECG. Data from !he 
cardiac rescue event, including the ECG recorded in real 
time, data from AED-deteclable events (e.g., check 
electrodes, place electrodes, rhythm analyzed, shock 
advised, shock delivered, etc.), and the audio recording are 
recorded internally within AED 22 for later downloading to 
a computer for further analysis. The date can also be stored 
onto a data storage card thai is removably insertable into 
AED 22, such as AED memory data card 24. AED memory 
data card 24 is, in turn, removably insertable into rescue 
scene computer 26, or into base computer 34, for transfer- 
ring the ECG and AED performance data from AED 22 into 
the respective rescue scene computer 26 or base computer 
34. Alternatively, the data can be downloaded from AED 22 
into rescue scene computer 26 via cable 43. 

Rescue scene computer 26 and base computer 34 are both 
general purpose personal computers well known in the art. 
For example, both rescue scene computer 26 and base 
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computer 34 include, at a minimum, a CPU such as a 
486SX-66 MHz (or faster) processor. Rescue scene com- 
puter 26 and base computer 34 also include sufficient RAM 
memory (e.g., 16 megabytes) and hard drive memory (e.g., 
5 80 megabytes) to store and operate Microsoft® Windows 95 
or NT and the database software (e.g., Microsoft® Access) 
supporting the system and method of the present invention, 
Rescue scene computer 26 includes any portable computer 
such as a laptop personal computer (PQ or a handheld PC. 

30 During a cardiac rescue event* a first responder or other 
operator uses AED 22 to defibrillate a cardiac arrest patient. 
Data representing the ECG and the AED/AED operator 
performance are recorded internally within AED 22 and then 
transferred onto AED data card 24. Next, this ECG/AED 

15 data are transferred into rescue scene computer 26 via cable 
43, or by removal of AED data card 24 from AED 22, and 
into rescue scene computer 26. In addition, while at the 
rescue scene, the first responder or other technician manu- 
ally enters patient and incident data regarding the cardiac 

20 rescue event into rescue scene computer 26. With all of the 
ECG data, AED data, and non-ECG data (e.g., patient and 
incident information) loaded into rescue scene computer 26, 
this entire set of data is transmitted via landline link 30 or 
wireless link 32 to base computer 34 at a central emergency 

2S medical system center 36. 

The ECG data, AED data, and non-ECG data are then 
observable together in an integrated fashion on base com- 
puter 34 in single screen graphical user interface 40, All of 
this data can be reviewed or modified as necessary, while 

3G additional information regarding the cardiac rescue event, 
including post event care and related emergency medical 
system performance, can be entered by the user through the 
single screen user interface 40 using input means 42. Using 
this technique, data are comprehensively and accurately 

35 captured to permit meaningful and rapid evaluation of each 
cardiac rescue event. Over time, as the system and method 
of the present invention is applied across localities, states, 
and nationally, for multiple cardiac rescue events, a tremen- 
dous database will be developed. This information will 

4 q greatly contribute to improving rescue techniques and 
understanding the delivery and effectiveness of emergency 
medical intervention. 

The remaining description explains single screen user 
interface 40 in greater detail, including how and where the 

45 ECG data, AED data, and non-ECG data are displayed as 
well as how other cardiac rescue event performance, 
evaluation, and reporting information is handled. 

FIG^ 2 is a schematic representation of single screen 
graphical user interface 40 permitting entry, review, and 

so revision of data regarding a cardiac rescue event. Interface 
40 defines single view screen 50 having resident 
components, such as rescue scene location 52., and selective 
viewing components, such as patient information tab win- 
dow 54, and optional ECG window 56. Tabs 55 mark access 

55 to selectable patient information tab window 54 as well as 
other selectable tab windows sucb as incident data window 
57, vitals and therapy window 5£> dispatch summary win- 
dow 60, AED data window 62, review window 64, AED 
evaluation window 66, and notes wimdew 68. Once a tab is 

60 selected, the window corresponding to that lab is displayed 
m an overlay fashion over the other tab windows. Data is 
entered via input means 42 into the dala fields visible in the 
selected window, which correspond directly with data fields 
of the database that operates in the background {not visible), 

65 Data fields within the tab windows include stored data in 
drop-down windows that can be selected and/or are capable 
of receiving manually entered new dala. 
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At the rescue scene* an operator fills in the data fields of 
rescue scene location screen 52 using input means 42 of 
rescue scene computer 26 to collect general information 
about the patient and the incident. As shown in FIG. 2> 
rescue scene location screen 52 includes the following data 5 
fields: incident ID 80, incident date 82, incident time 84, 
incident type 86, service area 88, rescue address 90 (street, 
city^ state, zip code, country, county), and geographic code 
92* Rescue scene location screen 52 always remains active 
in single screen user interface 40, Patient information tab 1Q 
window 54 includes the following data fields: patient name 
100 3 patient description 102 (such as date of birth, age, 
gender, race), patient address 104 (street, city, state, £ip 
code, county)* and patient telephone 106. 

FIG, 2 also shows ECG pull-up window 56 which grapfai- 33 
cally displays a real time representation of the ECG recorded 
during the cardiac rescue event with AED 22. ECG pull-up 
window 56 includes the following data fields: real time 
stamp HO, ECG waveform 112, and AED event stamp 114 
(e.g., electrodes placed, start of analysis, check elecsrodes). 20 
ECG window 56 defines a splitter window 115 that can be 
reduced or enlarged vertically on single screen user interface 
40. ECG window 56 also can be deactivated for selective 
removal from single screen user interface 40. All of the 
textual and graphically represented data in the ECG window 2 s 
56 is obtained from AED 22. 

When deployed in a handheld PC embodiment, rescue 
scene computer 26 operates a simpler graphical user inter- 
face like single screen user interface 40 that includes at least 
the corresponding data fields from patient information tab 30 
window 54 and incident information tab window 57 
(described below). 

The database supporting single screen graphical user 
interface 40 was constructed using Windows® operating 
system and Access® database system, both sold by 35 
Microsoft Corporation, Accordingly, the multiple tab win- 
dow structure within the single screen user interface 40, as 
well as the optional simultaneous ECG window 56, can be 
constructed by one skilled in the art using the tools and 
capabilities of Access® database program and Windows® 40 
operating system. In particular, the data access object (DAO) 
mode of the Access® program can be used to identify the 
desired data fields and relationship tables of the database, as 
well as the NHSTA codes further described below, The 
system and method of the present invention also includes an 45 
embedded registry of certain National Highway Safety Traf- 
fic Administration (NHSTA) codes that is linked to corre- 
sponding cardiac/accident rescue data fields. Hie NHSTA 
codes used in the method and system of the present inven- 
tion are published in Federal Information Standard (HPS) so 
Publication 28, and in International Classification of Disease 
and Related Health Problems Ninth Revision (1CD-9) and 
the Tenth Revision (ICD-10). The database is built in the 
open database connectivity format (ODBC) to permit data to 
be imported and exported entirely, or selectively, using an 55 
ODBC data management program such as Access®, 
FoxPro®, or SQL®, all known to those skiUed in the art. For 
example, a common ODBC program cap be used to extract 
all or some of the NHSTA-related data from the system To 
do so, the user identifies the tables and data fields carrying 60 
an embedded NHSTA code (or other desired category of 
information) and marks them for extraction. Once all of the 
NHSTA-related data are exported, it can be further manipu- 
lated by the ODBC program into a format suitable for 
reporting to national, state or local authorities. SimilarEy, 65 
data can be extracted for other reporting purposes such as 
UTSTEIN-style reporting to national, state or local 
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authorities, or for billing purposes with additional modifi- 
cation of the database of the method and the system of She 
present invention. 

The corresponding NHSTA codes for a given data field 
can be modified, added, or deleted by operating an edit list 
for the data field and then entering or editing the NHSTA 
code designation corresponding to that data field. For 
example, as shown in FIG. 2B, drop-down table 87A for the 
data field incident type 86 of rescue scene location 52 is 
selected, displaying several choices to fill this data field as 
well as "edit list" function 87B. By selecting the "edit list" 
function, another edit window, shown in FIG. 2C, is ulti- 
mately displayed on single screen user interface 40, which 
displays the data field, its entry, and the corresponding 
NHSTA code 87E for that entry. The default NHSTA code is 
displayed, if available, which can be modified, deleted, or 
added as necessary. 

FIG, 3 shows single screen user interface 40 with incident 
data tab window 57 selected and optional ECG window 56 
activated. Like patient tab window 54, incident tab window 
57 is used at the cardiac rescue scene to prompt the user to 
collect information about the incident, which will be trans- 
mitted to base computer 34 with patient data A ECG data r and 
AED data. Incident data tab window 56 includes the fol- 
lowing data fields: chief complaint 120, cause of injury 122, 
provider impression 124, pre-existing condition 126, signs 
and symptoms present 128, injury description 130, injury 
intent 132, incident/patient disposition 134, safety equip- 
ment 136, factors affecting EMS delivery 138, suspected 
alcohol/drug abuse 140. 

FIG. 4 shows single screen user interface 40 with vitals 
and therapy tab window 58. The patient vitals and therapy 
data are typically collected at the cardiac rescue scene with 
the other patient data (tab window 54) and included for 
transmission with the ECG data to base computer 34, Once 
the vitals and therapy tab is selected, window 58 displays 
and includes the following data fields: respiratory rate 150, 
respiratory effort 152, blood pressure 154, skin perfusion 
156, with Glasgow evaluation 158 (including eye opening, 
verbal component, motor component, corn a score, and 
revised trauma score), modified therapy list 160 (including 
therapy name, therapy time, therapy performer, and notes). 

FIG. 5A shows single screen user interface 40 with 
dispatch summary tab window 60 selected, and which 
includes the following data fields for first responder 170, 
second responder 172, and third responder 174: responder 
facility 176, vehicle type 178, dispatch ID 180, crew mem- 
bers 182, lights used 184, sirens used 186, transported 
patient 188, and location to which patient was transported 
190. As shown in FIG. SB t a lower portion of dispatch 
summary tab window 60 includes additional data fields for 
each of first* second and third responder times 191 com- 
prising: unit dispatched 192, unit notified 193, unit respond- 
ing 194, arrival at scene 195* arrival ai patient 196, dis- 
patched from scene 197 s arrival al destination 198, and unit 
back in service 199. The data in the dispatch summary tab 
window can be entered into the system by rescue personnel 
either at the cardiac rescue scene and during continuing 
emergency medical service (e,g„ transport to a hospital), or 
can be entered into the singJe screen user interface at base 
computer 34 at a later time with information obtained from 
the rescue dispatch team after the rescue team reports its 
activities back to the rescue dispatch cenier. 

FIGS, 6A-6B show single screen user interface 40 with 
AED data tab window 62 selected, which Includes the 
following data Selds: AED serial number 200 ? model mim- 
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ber 202, AED operator 204, and AED history 206 including 
event 208 (AED lid opened, electrodes placed , . . , shock 
advised), actual time 210 (i.e., real time), elapsed time 212, 
and communis 214 as well as first dc fibril la ting shock time 
215, initial rhythm 216 (e.g., ventricular fibrillation), initial 5 
rhythm converted to rhythm 217 (e.g., ventricular 
fibrillation). Additional data fields in AED data lab window 
62 primarily relate to UTSTEIN-style reporting of out-of- 
hospital cardiac arrests, and include: provider type of first 
CPR 218, time of first CPR 219A, time CPR discontinued 1Q 
219B, witness type of cardiac arrest 220, witnessed cardiac 
arrest 221, confirmed cardiac arrest 222, initial cardiac 
rhythm shocked 223, and return of spontaneous circulation 
(ROSQ 224, cardiac etiology 225, resuscitation attempted 
226. Finally, tab window 62 includes display AED operating 15 
parameters lookup window 227, and battery information 
look-up window 228, Most of the AED- and ECG-related 
data fields in AED data tab window 62 is automatically 
entered into the method and system of the present invention 
when this data is downloaded from AED 22 into rescue 2Q 
scene computer 26 and/or base computer 34. Of course^ 
those data fields not filled in by data from AED 22 are filled 
in manually by an operator at the rescue scene or at a later 
lime by a reviewer 

FIG. 7Ashows single screen user interface 40 with review 25 
tab window 64 selected, which includes the following data 
fields: daLe of review 230, emergency room information 232* 
intensive care unit information 234, hospital information 
236, This information is entered into the system by the 
reviewer away from the cardiac rescue scene. Emergency 30 
room information 232 , intensive care unit information 234, 
and hospital information 236 each include the following data 
fields: admitted to ER (or ICU or hospital) 240, name of ER 
(or ICU or hospital) 242, admission date 244, admission 
time 246, discharge date 24$, discharge time 250* and 35 
patient died within 24 hours 252. Hospital information 236 
further includes the data field, alive after one year of 
discharge 254, FIG, 7B shows a lower portion of review tab 
window 64 t which includes the following additional data 
fields: updated Glasgow evaluation 255 (including eye ^ 
opening, verbal, and motor components, with total score), 
patient status 256 (including alive, alive after first year, 
scene of death, daie of death, and time of death), and review 
status 258 (including review completed, review due date, 
reviewer name). 45 

FIG. 8 shows single screen user interface 40 with AED 
and responder evaluation tab window 66 selected, and which 
includes the following data fields: bystanders stand clear 
instruction 260, airway intervention 262, patient not 
conscious, not breathing, and no pulse 264, AED function 50 
properly 266, incident investigation required 268, AED 
deliver one or more shocks 270, AED applied to appropriate 
patient 272, CPR initiated at appropriate time 274, CPR 
resumed at appropriate times 276, EMS arrive at patient's 
side during incident 278, and score 280, This evaluation tab 55 
window is used for evaluating the AED and AED operator 
performance, 

FIG. 9 shows single screen user interface 40 with notes 
tab window 68 selected. This tab window is for provided for 
a reviewer to make notes regarding any aspect of the cardiac 60 
rescue under review. 

The system and method of the present invention is also 
capable of generating many types of reports by grouping a 
selected combination of data fields from one or more tab 
windows from single screen user interface 40, FIG. 1© 65 
shows an UTSTEIN data report 300 on cardiac arrest 
incidents for ventricular tachycardia with no-bystander 
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CPR. This report follows the Utslein Style Guidelines for 
Uniform Reporting of Data from Out-of-Hospitai Cardiac 
Arrest Reports similar to report 300 are available for 
ventricular tachycardia with bystander CPR* ventricular 
fibrillation with no-bystander CPR, ventricular fibrillation 
with bystander CPR, asystole with no-bystander CPR, and 
asystole with bystander CFR. Each UTSTEiN report 
includes the following data fields: service area 310, popu* 
lalion served 312, confirmed cardiac arrests considered for 
resuscitation 314, resuscitations attempted 316, resuscita- 
tions not attempted 318, cardiac etiology 320, non-cardiac 
etiology 322, arrest witnessed (bystanders) 324, arrest not 
witnessed 326, arrest witnessed (EMS personnel) 328, initial 
rhythm VT330, other initial rhythms 332, no bystander CPR 
334, bystander CPR 336, any resuscitation on spontaneous 
circulation (ROSQ 338, never achieved (ROSQ 340, 
admitted to ICU/ward 342, efforts ceased 344 (expired is 
field or in ED), discharged alive 346, expired in hospital 348 
(total or within 24 hours), alive at one year 350, and expired 
wiLhin one year of discharge 352. 

Many other reports can be obtained which provide a prist 
out of a selected combination of data fields from one or more 
tab windows of single screen user interface 40, For example, 
standard reports include dispatch summary, incident 
summary, post-market surveillance, ECG summary, and 
patient follow-up, etc. 

in addition to managing the effectiveness of a single or 
multiple cardiac rescue event, the system and method of the 
present invention also can be used to track the use and 
location of AEDs as well as facilitate training of AED 
operators, 

FIG. 11 shows single screen user interface 40 with 
optional AED deployment tracking tool window 400 
selected, which includes the following data fields: AED 
operator 402, AED/Battery information 404, and AED loca- 
tion 406. AED/battery information 404 further includes 
serial number 410, model number 412, AED ID 414, and 
battery ID 416. AED location 406 further includes type of 
location 418 (e.g., ground), VIN 420, address 422 (street, 
city, state, zip, telephone), and geographic code 424. Of 
course, most of this AED data will be loaded into these data 
fields automatically when the AED data from AED 22 is 
transmitted from AED 22 into rescue scene computer 26 aod 
then into base computer 34. 

FIG. 12 shows single screen user interface 40 with 
optional operator training tool window 430 selected, which 
includes the following data fields: operator trained 432 
(name, ID, title) and both AED training specifics 434 and 
CPR iraining specifics 436, each including training per- 
formed by, date of last training, total number of hours 
trained, further training by. This data facilitates training of 
AED operators and tracking of who and how many people 
are trained AED operators. 

The system and method of the present invention have 
numerous advantageous features. First, a programmed res* 
cue scene computer permits user-observed patient and inci- 
dent data to be transmitted simultaneously with transmission 
of ECG dala and AED data from the rescue scene to a base 
computer This on-scene data collection and simultaneous 
transmission with the ECG data permits the AED to remain 
in the field for nearly immediate use in another cardiac 
rescue event. Second, once the ECG data, AED data, and 
non-ECG data (patiem and incident information, etc.) are in 
the system, the ECG data is selectively displayed simulta- 
neously with AED data and/or non-ECG patient and incident 
data on a single screen graphical user interface. This feature 
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greatly facilitates review of the data and ECG since the 
reviewer need not switch back arid forth between a aon-ECG 
data or notes/review screen and the ECC data screen during 
review. Third, ECG data and AED data imported from the 
AED, as well as non-ECG data such as patient and incident 5 
data, are automatically registered with corresponding pre- 
determined NHSTA codes (or other desired codes) to permit 
later reporting of the cardiac rescue data in national report- 
ing formats. The NHSTA code registry can be modified on 
a code-by-code basis and can be selectively deactivated, 10 
Fourth, tbe data fields are based on an Open Database 
Connectivity (ODBC) format to permif import and export of 
cardiac rescue data to and from other emergency medical 
event database management systems, as well as permitting 
customized reporting by using another ODBC reporting 15 
database management software. Together, these features 
elevate cardiac emergency medical system management to a 
new level, providing comprehensive and coherent integra- 
tion of all event and post-event data into a single system. 
This system and method permits internal or national report- 20 
ing and rapid assessment and evaluation of the cardiac 
rescue event. Over time ? this system and raemod will 
contribute greatly to future benchmarking of cardiac rescue 
event responses and management, particularly those involv- 
ing AEDs. 25 
What is claimed is: 

1. A metbod of managing cardiac rescue events compris- 
ing tbe steps of: 

performing a cardiac rescue on a patient at a cardiac 
rescue site with an automated external defibrillator 30 
(AED); 

collecting ECG data at the cardiac rescue event at the 

cardiac rescue site; and 
collecting automated AED rescue data of the cardiac 35 

rescue event at the cardiac rescue site presenting the 

ECG data and AED rescue data on a screen of a rescue 

scene computer at the cardiac rescue site. 

2. The method of claim 1 and further comprising: 
displaying the ECG data graphically on a display screen 40 

simultaneously with the non-ECG rescue data. 

3. The method of claim I further comprising: 
reviewing the cardiac rescue event by viewing the ECG 

data on the display screen; and 
inputting analytical observations regarding the cardiac AS 

rescue event during the reviewing siep. 
4 r The method of claim 2 tether including displaying the 
ECG data graphically in real time. 

5. The method of claim 1 further including the step of 
displaying the ECG data and AED Fescue data in a real time 50 
enactment of the cardiac rescue event. 

6. The method of claim 1 further comprising: 
collecting AED rescue data Including at least one of the 

following: 55 
patient information, rescue scene location information, 
incident and rescue scene assessment information, 
patient vitals and therapy information, therapy 
information, rescue dispatch and response information, 
and AED operator performance information. 6{} 

7. The method of claim 6 further comprising: 
collecting incident information/rescue scene assessment 

including chief complaint, cause of injury, provider 
impression, pre-existing condition* signs and 
symptoms, injury description, injury intent, incident/ 
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patient disposition, safety equipment, factors affecting 
EMS delivery, suspected drug or alcohol abuse. 

8. The method of claim 1 further comprising: 
collecting patient vitals and therapy information including 

respiratory rate, respiratory effort, blood pressure, skin 
perfusion and Glasgow information including eye 
opening, verbal component, motor component, coma 
score, and therapy including therapy provider, therapy 
name, and lime of therapy. 

9. The method of claim 1 further comprising: 
collecting dispatch and response information including at 

least one of the following: responder facility, vehicle 
type, dispatch ID and crew members, lights used, sirens 
used* location of hospital patient transported to, unit 
dispatched, unit notified, unit responding, arrival at 
scene, arrival at patient, departure from scene, arrival at 
destination, and unit back in service, 

10. The method of claim 1 further comprising: 
collecting AED rescue data including at least one of the 

following: an AED serial number, AED model number, 
AED operator, the real time of and occurrence of the 
following events: AED Hd opening, electrode place- 
mem on patient, start of analysis, electrode checking, 
start of charge, advising operator of shock, delivering 
shock to patient. 

11. Hie method of claim 1 further comprising: 
collecting AED rescue data including at least one of the 

following: first defibrillating shock time, initial rhythm, 
initial rhythm conversion. 

12. The method of claim 1 further comprising: 
collecting AED rescue data including at least one of the 

following: provider type of first CPR } time of first CFR* 
time CPK discontinued, 
witness type of cardiac arrest, witnessed cardiac arrest t 
confirmed cardiac arrest, initial cardiac rhythm 
shocked, return of spontaneous circulation, cardiac 
etiology, and resuscitation attempted, 

13. The method of claim 1 further comprising: 
coDecting review data including at least one of the fol- 
lowing: review date; admitted to ER, ICU t or hospital; 
name of ER, 1CU, or hospital; admission date; admis- 
sion time; discharge date; discharge time; patient died 
within 24 hours; alive after one year of discharge; 
update Glasgow evaluation including eye opening, 
verbal, and motor components; patient status including 
alive, alive after first year, scene of death, date of death, 
and time of death; and review status including review 
completed, review due date, reviewer name. 

14. Tbe method of claim 13 further comprising: 
establishing a link between a predetermined NHTSA code 

to a corresponding ECG data or AED rescue data, 

15. The method of claim 1 further comprising: 
operably communicatively coupling the AED to the res- 
cue site computer for the automated interchange of 
certain data therebetween; and 

embedding the predetermined NHSTA code in a back- 
ground of active data fields to permit selective 
activation, deactivation, modification, and/or initializa- 
tion thereof. 

16. The method of claim 1 further comprising simulta- 
neously presenting the ECG data and AED rescue on a single 
screen graphical user interface of the rescue scene computer. 

$ * $ * $ 
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ABSTRACT 



An electronic mailing method on the Internet with a function 
of reception confirmation is described. The method is com- 
prising the steps of (a) assigning a unique code to the e-mail 
of a sender and recording toe unique code in a database; (b) 
attaching to the e-mail a CGI executive program that auto- 
maiic&Hy sends the unique code to the web server of the 
sender when the receiver receives the e-mail; {c) sending the 
unique code to the web server of the sender by the automatic 
execution of the CGI executive program when the e-mail is 
received by the receiver; and (d) comparing the unique code 
sent in the step (c) and the unique code recorded in the step 
(a) and, if they are identical, sending reception confirmation 
information to the sender 

3 Claims, 5 Drawing Sheets 
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REGISTRATION MAIL SYSTEM WITH A 
SENT E MAIL CHECK FUNCTION ON 
INTERNET AND METHOD FOR THE SAME 



BACKGROUND OF THE INVENTION 
1, Field of the Invention 

Tbe present invention relates to a mail system and method 
for solving the problem that a sender cannot check whether 
or not a receiver received (read) a mail io an internet 
environment (FIG, 2) that is a switching system among mail 
servers independently operated . 

2- Description of Related Art 

Existing PC communication services (e.g., Chollian, 
Hitel, Nownuri, and Unitel in Korea) each provides a sent 
e-mail check function in exchanging mail between its own 
service users. This is possible because the service is a single 
mail system. However, the mail exchange between users of 
duTerent services cannot be achieved. Namely, messages can 
be exchanged by e-mail only be 5 wee ri users registered in the 
same service (FIG. 1). 

On tbe other hand, users can freely exchange their mes- 
sage by e-mail regardless of services in which they regis- 
tered according to the mail exchange system in the internet 
environment. Therefore, the existing PC communication 
services tend to provide an internet mail service together and 
the communication tends to be used based upon internet 
mail IDs (e-mail addresses). However, tbe existing internet 
mail service cannot provide a function allowing a sender to 
check whether or not a receiver read tbe mail sent by the 
sender, This is because internet mails are exchanged 
between independent mail servers. In this system, the sender 
cannot check the mail that the sender has sent to the 
receiver's mail server (FIG. 2). 

SUMMARY OF THE INVENTION 

Accordingly, the present invention is directed to a regis- 
tration mail system with a sent e-mail check function on 
internet and method for the same that substantially obviates 
one or more of the limitations and disadvantages of ihe 
related art. 

An objective of the present invention is to provide a 
registration mail system with a sent e-mail check function, 
wherein a unique code is given to each mail sent by a sender 
and recorded in a database (DB), a common gate interface 
(CGI) executive program through which the unique code 
and confirmation information are sent to a source mail 
system if a receiver reads the mail is attached to the mail 
itself which is sent to the receiver*? mail server, if the 
receiver reads the mail, the unique code and confirmation 
information that have been sent to the mail center by the CGI 
executive program are compared with database information 
and recorded in the database, and confirmation of reception 
by the receiver is notified to the sender- 
Additional features and advantages of the invention will 
be set forth in the following description, and in part will be 
apparent from tbe description, or may be learned by practice 
of the invention. The objectives and other advantages of the 
invention will be realized and attained by the structure as 
illustrated in the written description and claims hereof „ as 
well as the appended drawings. 

To achieve these and other advantages, and in accordance 
with the purpose of the present invention as embodied and 
broadly described, the present invention employs a mail 
control system for assigning a unique code to a mail sept by 
a sender, recording the code in a database, and attaching a 
CGI executive program to the mail. The mail control system 
organically acts with a mail server and is in linkage with a 
database. 
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The present invention also employs another mail control 
system for comparing reception confirmation information 
from a receiver with database information, recording tbe 
confirmation information in ihe database, and sending an 
5 informing signal to the sender. This mail control system 
organically acts with a web server and is in linkage with the 
database. 

When the receiver reads the mail in an off-line state, if a 
mail client application used by the receiver for reading the 

3€ mail does no! support a hypertext markup language 
{HTML), or if a text based emulator is used for reading the 
mail, the above system cannoi be applied, so a registration 
mail system is developed as an extended type based upon the 
above system. In stead of using the program attached to the 
mail to process the reception confirmation information, the 

25 registration mail system stores tbe text of the mail therein 
and first sends only the information of a title of the mail, 
registration mail reception link, and registration mail guide 
note to the receiver. If the receiver requests tbe text of the 
mail, the registration mail system sends the text of the mail 

20 to the receiver and records the reception of the mail in ihe 
database. 

It is to be understood that both the foregoing general 
description and the following detailed description are exem- 
plary and explanatory and are intended to provide furtbeF 
25 explanation of ihe invention as claimed . 

BRIEF DESCRIPTION OF THE ATTACHED 
DRAWINGS 

The accompanying drawings, which are included to pro- 
vide a further understanding of tbe invention and are incor- 
porated in and constitute a part of this specification, illustrate 
embodiments of the invention and together with the descrip- 
tion serve to explain the principles of the invention. 
35 In the drawings: 

FIG, 1 is a block diagram showing a conventional mail 
system in PC communication; 

FIG. 2 is a block diagram showing a conventional e-mail 
system in an internet environment; 
40 FIG. 3 is a block diagram showing an overall structure of 
a mail system with a sent e-maii check function according to 
the present invention; 

FIG, 4 is a block diagram showing an overall structure of 
an embodiment of a registration mail system with an 
4 5 extended sent e-mail check function according to the present 
invention; and 

FIG. 5 is a block diagram showing an overall structure of 
another embodiment of a registration mail system with an 
extended sent e-mail check function according to the present 
5D invention. 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENT 

Reference will now be made in detail to the preferred 
55 embodiments of the present invention, examples of which 
are illustrated in the accompanying drawings- 

With reference to the accompanying drawings, the present 
invention will be described in detail. 

FIG. 3 is a block diagram showing an overall structure of 
60 a mail system with a sent e-mail check function, Once a user 
composes a mail message and send it through this system., 
ihe mail is processed by a mail control system A which 
organically acts with a mail server. At this time* a unique 
code is assigned to the mail and the related information is 
65 recorded in a database. The mail control system A attaches 
the unique code and CGI executive program to the mail 
before sending it to the mail server of a receiver. If the 
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receiver reads the arrived mail, the CGI executive program 
is carried out so as to send information confirming the read 
of the message by the receiver and the unique code of the 
mail to a mall control system B in a mail center. The 
received mail code is compared with the mail codes previ- 5 
ously recorded in the database to find the same mail code, 
Reception confirmation inform alien is added to the corre- 
sponding mail record in the database. Thereafter, the mail 
control system B sends a reception confirmation signal to the 
sender. Furthermore, the sender can check the sent mail after 
accessing the web server anytime when necessary (FIG- 3). 

A registration mail system extended from the above 
system is similar to tbe above system in that a unique code 
Is assigned to a mail sen! by a sender. However, differently 
from the above system, the text of the mail is separately ^ 
stored and a registration mail reception link and a registra- 
tion mail guide note (indicates registration mail receive 
method for a user checking e-mail with an emulator based 
upon text) are attached 10 the mail in the mail center before 
sending the mail to the receiver's mail server, Once the 
receiver receives (reads) the mail, the texi of the mail stored 20 
is requested through the registration mail reception link 
attached to the mail. The mail text is then received by the 
receiver through direct connection, Ai this time, the mail 
control system B compares the unique code of the mail with 
the mail codes in the database and adds reception confir- 25 
mation information to the record of the corresponding mail 
in the database, Subsequently, the mail control system B 
sends the reception confirmation signal to the sender. 
Furthermore, the sender can check the sent mail after 
accessing tbe web server anytime when necessary (FIG, 4). 3D 

However, if a mail client application used by the receiver 
for checking e-mail does not support HTML, or if the 
receiver checks the e-mail using the text based emulator, the 
above system cannot be applied. In this occasion, once the 
receiver just replies according to the content of tbe regis- 35 
tration mail guide note, tbe mail control system A requests 
tbe text of the mail stored in the DB and sends it to the 
receiver, Tbe mail control system A compares the unique 
code of tbe mail with the mail codes recorded in the DB and 
adds the reception confirmation information to the record of 
the corresponding mail. Thereafter, the mail control system 40 
B sends tbe reception confirmation signal to the sender. 
Furthermore, the sender can check the sent mail after 
accessing the web server anytime when necessary (FIG. 5). 

Consequently, tbe present invention makes ii possible to 
use a sent mail check function on internet, thereby over- 45 
coming the defect of the interne! e-mail thai has been the 
main method for mail exchange. 

As illustrated, tbe present invention embodies an internet 
mail system supporting a sent mail check function. This is 
sufficiently important to the part of e-mail as means of 50 
communication, For example, when the e-mail is used for 
business, there may be some cases tbe success of the 
business depends on whether or not the receiver reads within 
a certain time limit. There may be some cases that reception 
itself is refused or that a sender cannot check whether or not 55 
the receiver reads the mail by phone or other means. The 
sent mail check function is very important to the sender in 
these cases as well as daily mail exchange. Jn case a receiver 
uses a plurality of e-mail addresses, the present invention 
makes it possible for a sender to find and send e-mail to the 60 
receiver's e-mail address that is not used frequently. As 
illustrated, the sent mail check function is very useful- As 
internet e-mail becomes more important and necessary as 
means of communication, effect of the sent mail check 
function achieved by the present invention increases, ^ 

It will be apparent to those skilled in the art that various 
modifications and variations can be made in the registration 
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mail system with a sens e-mail check function on internet 
and method for the same of the present invention without 
deviating from the spirit or scope of the invention. Thus t it 
is intended that the present invention covers the modifica- 
tions and variations of this invention provided they come 
within the scope of the appended claims and their equiva- 
lents. 

What is claimed is: 

1. An electronic mailing method on the Internet with a 
function of reception confirmation comprising; 

(a) assigning a unique code to an e-mail of a sender and 
recording io a database the information on the unique 
code assigned to the e-maO; 

(b) attaching to the e-mail, to which the unique code was 
assigned in the step of (a), a CGI (common gateway 
interface) executive program that automatically sends 
to the web server of the sender the unique code that was 
assigned in the step (a) when the receiver receives the 
e-mail; 

(c) sending the unique code of the received e-mai! to the 
web server of the sender by tbe automatic execution of 
the CGI executive program when the e-mail, to which 
the unique code was assigned in the step of (a) and to 
which the CGI executive progFam was attached in the 
step of (b), is received by the receiver; and 

(d) comparing the unique code of e-mail that was sent in 
the step (c) and the unique code that was recorded in the 
step (a) and, if they are identical, sending reception 
confirmation information io tbe sender. 

2. An electronic mailing method on the Internet with a 
function of receipt confirmation, comprising the steps of: 

(a) assigning a unique code to an e-maii sent by a sender 
and storing the unique code in a database; 

(b) attaching a CGI executive program to the e-mail 
containing the unique code of step (a) in order to 
transmit the unique code which is assigned to the 
e-mail in step (a), to an e-mail system of tbe sender 
upon a receivers receipt of the e-mail; 

(c) transmitting the unique code of the e-mail received by 
the receiver to the e-mail mail system of the sender by 
an automatic execution of the CGI executive program 
upon the receiver's receipt of tbe e-mail which contains 
tbe unique code and tbe CGI executive program of step 
(b); and 

(d) delivering receipt confirmation information to the 
sender of the e-mail if the unique code of the e-maii 
transmitted in step (c) is identical to the information 
stored in the database. 

3. An electronic mailing system on the Internet with a 
function of receipt confirmation, comprising: 

a first mail control system having a mail processor part 
which assigns a unique code to e-mail sent by a sender, 
attaches a CGI executive program for e-mail transmit- 
ting the assigned unique code to the electronic mailing 
system upon a receiver's receipt of the e-mail, and 
transmits the e-mail to the receiver's mail server; 

a database in which the unique code assigned by the mail 
processor part is recorded; and 

a second mail control system having a receipt confirma- 
tion part which receives the unique code of the e-mail 
transmitted by automatic execution of the CGI execu- 
tive program^ compares the transmitted unique code 
with tbe unique code recorded in the database, and 
transmits receipt confirmation information to the 
sender if the two unique codes are identical, 

$ # $ * * 
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00RBA n. Acronym for Common Object Request Broker 
^chitecture, A specification developed by the Object 
M$ Management Group in 1992 in which pieces of programs 
(objects) communicate with other objects in other pro- 
| grams, even if the two programs are written in different 
|K j^gjamming languages and are running on different plat- 
^Maipis- A program makes its request for objects through an 
|j ||&- object request broker, or ORB, and thus does not need to 
|f^kobw the structure of the program from which the object 
S ^-^ifiQes- CORBA is designed to work in object-oriented 
-• ehyironrnen ts . See also HOP, object (definition 2), Object 
^I j^jaagement Group, object-oriented. 

w l$j^h. One of the types of" memory built into computers 
;|?j^JcKre: random access memory (RAM) was available or 
E - ^di^able. Some people still use the term to refer to the 
v .memory of any computer system, as in the phrase 

mp — a listing of the raw contents of main memory 
moment of a system crash. Compare RAM. 

; class n. In the Java programming language, a public 
s or interface that is a standard member of the lan- 
^Cpre classes, at minimum, are available on ail 
\. systems where the Java platform runs. A prew- 
ritten entirely in the Java programming language 
£&aly-on core classes. See also class (definition .1), 
$^ect-oriented programming. 

am A program or program segment that is 
giitTandom access memory (RAM). 

ixtdj. Of or pertaining to a condition in which 
programs are loaded in memory at the same 

j|& In laser printers, a wire though which high 
^J^sed to ionize the air and transfer a uniform 
Ifharge to the photosensitive medium in prep- 



^.routine that is in memory at the same time 
^executed concurrently with, another. 

(itenance n. The process of diagnosing 

puter problems after they occur. Com- 
ft^ihtenance. 

Quality n. See print quality. 

cess wherein data in memory or on 
ly changed, with its meaning thereby 
eft 



cost-benefit analysis n. The comparison of benefits to 
costs for a particular item or action. Cost-benefit analysis 
is often used in MIS or IS departments to determine such 
things as whether purchasing a new computer system is a 
good investment or whether hiring more staff is necessary. 
See also IS, MIS. 

coulomb n. A unit of electrical charge equivalent to 
roughly 6.26 x 1 0 3 8 electrons, with a negative charge 
being an excess of electrons and a positive charge being a 
deficiency of electrons. 

counter n. 1. In programming, a variable used to keep 
count of something. 2. In electronics, a circuit that counts 
a specified number of pulses before generating an output. 
3, A device that keeps track of the number of visitors to a 
World Wide Web site. 

counting loop ru In a program, a group of statements that 
are repeated, thereby incrementing a variable used as a 
counter (for example, a program might repeat a counting 
loop that adds I to its counter until the counter equals 10). 
See also loop 1 (definition 1), 

country code ». See major geographic domain. 

country-specific adj. Of, pertaining to f or characteristic 
of hardware or software that uses characters or conven- 
tions unique to a particular country or group of countries. 
Country-specific does not necessarily refer to spoken lan- 
guages, although it does allow for special characters (such 
as accent marks) that are language-specific. Generally, the 
features considered country-specific include keyboard lay- 
out (including special-character keys), time and date con- 
ventions, financial and monetary symbols, decimal 
notation (decimal point or comma), and alphabetic sorting 
order. Such features are handled either by a computer's 
operating system (for example, by the Keyboard and 
Country commands in MS-DOS) or by application pro- 
grams that offer options for tailoring documents to a par- 
ticular set of national or international conventions, 

courseware n. Software dedicated to education or training, 

courtesy copy n. See cc. 

CPA «. See Computer Press Association. 

CPCP n. See HTCPCR 

cpi n. See characters per inch. 

CP/M n. Acronym for Control Program/Monitor. A line * 
of operating systems from Digital Research, Inc. (DRJ), 
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> insider attack n. An attack on a network or system car- 
ried out by an individual associated with the hacked sys- 
tem. Insider attacks are typically the work of current or 
former empJoyees of a company or organization who have 
knowledge of passwords and network vulnerabilities. 
Compare intruder attack. 

ins key «, See Insert key. 

install vb. To set in place and prepare for operation. Oper- 
ating systems and application programs commonly 
include a disk-based installation, or setup, program that 
does most of the work of preparing the program to work 
with the computer, printer, and other devices. Often such a 
program can check for devices attached to the system, 

I request the user to choose from sets of options, create' a 
place for the program on the hard disk, and modify system 
startup files as necessary. 

installable device driver n. A device driver that can be 
embedded within an operating system, usually in order to 
p override an existing, less-functional service. 

Installable File System Manager n. In Windows 9x 
and Windows 2000, the part of the file system architecture 
responsible for arbitrating access to the different file sys- 
tem components. Acronym; IFS. 

installation program n. A program whose function is to 
install another program, either on a storage medium or in 
memory. An installation program, also called a setup pro- 
gram, might be used to guide a user through the often 
complex process of setting up an application for a particu- 
lar combination of machine, printer, and monitor, 
installer n. A program, provided with the Apple Macin- 
tosh operating system, that allows the user to install sys- 
tem upgrades and make bootable (system) disks. 
Instance n. An object, in object-oriented programming, 
in relation to the class to which it belongs. For example, an 
object myUst that belongs to a class List is an instance of 
the class List. See also class, instance variable, instantiate 
object (definition 2), 

instance variable ?l A variable associated with an 
instance of a class (an object). If a class defines a certain 
variable, each instance of the class has its own copy of that 
variable. See also class, instance, object (definition 2), 
object-oriented programming. 

Instantiate vb To create an instance of a class. See also 
class, instance, object (definition 2), 



instant messaging n.A service mat alerts users when 
fnends or colleagues are on line and allows them to com- 
municate with each other in real time through private ' " : 
online chat areas. With instant messaging, a user creates a : 
list of other users with whom he or she wishes to commu- 
mcate; when a user from his or her list is on line, the ser- ■ ■ 
vice alerts the user and enables immediate contact with the ' ; 
other user. While instant messaging has primarily been a 
proprietary service offered by Internet service providers 
such as AOL and MSN, businesses are starting to employ - 
instant messaging to increase employee efficiency and 
make expertise more readily available to employees, 

institute of Electrical and Electronics Engineers n 

See IEEE, 

instruction «. An action statement in any computer lan- 
guage, most often in machine or assembly language Most 
programs consist of two types of statements: declarations 
and instructions. See also declaration, statement, 
instruction code n. See operation code, 
instruction counter n. See instruction register, 
instruction cycle n. The cycle in which a processor 
retrieves an instruction from memory, decodes it, and car- 
ries it out. The time required for an instruction cycle is the 
sum of the instruction (fetch) time and the execution 
(translate and execute) time and is measured by the num- 
ber of clock ticks (pulses of a processor's internal timer) 
consumed. 

instruction mix ru The assortment of types of instruct 
dons contained in a program, such as assignment instruc- 
tions, mathematical instructions (floadng-poim or 
integer), control instructions, and indexing instructions. 
Knowledge of instruction mixes is important to designers 
of CPUs because it tells them which instructions should be 
shortened to yield the greatest speed, and to designers of 
benchmarks because it enables them to make the bench- 
marks relevant to real tasks. 

instruction pointer n. See program counter, 
instruction register n. A register in a central processing 
umt that holds the address of the next instruction to be 
executed. 

instruction set n. The set of machine instructions that a 
processor recognizes and can execute. See also assembler, 
microcode. 
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Web applications, since users access the Web from many 
^ types of computers. Java is used in programming small 
applications, or applets, for the World Wide Web, as well 
as in creating distributed network applications. See also 
bytecode, Java applet, Jini, object-oriented programming. 

Java applet n. A Java class that is loaded and run by an 
already-running Java application such as a Web browser or 
an applet viewer. Java applets can be downloaded and run 
by any Web browser capable of interpreting Java, such as 
Internet Explorer, Netscape Navigator, and Hotjava. Java 
applets are frequently used to add multimedia effects and 
interactivity to Web pages, such as background music, 
real-time video displays, animations, calculators, and 
interactive games. Applets can be activated automatically 
when a user views a page, or they may require some action 
on the part of the user, such as clicking on an icon in the 
Web page. See also applet, Java. 

JavaBean n, A Java component architecture defined in 
fee JavaBeans specification developed by Sun Microsys- 
tems, A JavaBean, or Bean, is a reusable application com- 
ponent — an independent code segment — that can be 
combined with other JavaBean components to create a 
Fava applet or application. The JavaBean concept empha- 
sizes the platform-independence of the Java language, in 
vhjch ideally a program, once written, can run on any 
:omputing platform. JavaBeans are similar to Microsoft's 
ActiveX controls. ActiveX controls, however, can be 
leveloped in different programming languages but exe- 
uted only on a Windows platform. JavaBeans can be 
eveloped only in the Java programming language but ide- 
lly can run on any platform. See also ActiveX, Java. 

ava Card n. An application programming interface 
\PI) from Sun Microsystems, Inc„ that allows Java 
3p]ets and programs to run on smart cards and other 
2vices with limited memory. Java Card uses a Java Card 
irtuaj Machine designed for severely memory-con- 
rained devices- See also appiets, Java Card Virtual 
achine, smart card (definition 2). 

va Card Virtual Machine n. An ultra-smai^footprint, 
shiy optimized foundation of a runtime environment 
thin the Java 2 Platform Micro Edition. Derived from the 
/a Virtual Machine (JVM), it is targeted at smart cards 
i other severely memory-constrained devices. The Java 
rd Virtual Machine can run in devices with memory as 
all as 24 KB of ROM, 16 KB of BEPROM, and 512 
es of RAM. See also BEPROM, Java Card, RAM, 



Java chip 72- An implementation on a single integrated 
circuit of the virtual machine specified for execution oft 
Java programming language- Such chips, which are beiif| 
developed by Sun Microsystems, Inc., could be used in 
very small devices and as controllers for appliances. See$ 
also integrated circuit, Java, virtual machine. 

Java-compliant browser «. A Web browser wi th supporfj 
for the Java programming Jang mage built into it. Most 
current Web browsers are Java-compliant, See also JavaJ 
Web browser. 

Java Developer's Krt n. A set of software tools devel- 
oped by Sun Microsystems, Inc., for writing Java applets 
or applications. The kit, which is distributed free, includes 
a Java compiler, interpreter, debugger, viewer for applets, 
and documentation. Acronym: JDK. See also applet, Java, 
Java applet. 

Java Foundation Classes n. A Java-based set of class 
libraries developed by Sun Microsystems, Inc. Encom- 
passing fundamentals of the Internet Foundation Classes 
created by Netscape Communications Corp., the Java 
Foundation Classes extend the Java Abstract Window 
Toolkit (AWT) by providing graphical user interface 
components for use in developing commercial and 
Internet-related Java applications. See also Abstract Win- 
dow Toolkit, Application Foundation Classes, Internet 
Foundation Classes, Java, JavaBean, Microsoft Founda- 
tion Classes. 

Java HotSpot ru A Java performance engine introduced 
by Sun Microsystems, Inc., in 1999 that is designed to run 
Java applications faster than just-in-time (JIT) compilers. 
The core of Java HotSpot, and the feature for which jt is 
named, is its ability to perform adaptive optimization — the 
identification and optimization of "hot spots" or sections 
of performance-critical code. Improved garbage collection 
(freeing of memory occupied by objects no longer in use) 
and better multithreading are additional features designed 
to contribute to increased performance. See also Java. 

Java IDt n. Short for Java Interface Definition Language. 
A Java technology that provides CORBA interoperability 
and connectivity capabilities for the Java platform. These 
capabilities enable Java applications to invoke operations 
on-remote network services using the Object Management 
Group Interface Definition Language and Internet Inter- 
ORB Protocol. See also CORBA, IDL, J2EE RMMOP. 

Java Mai! n. An API in the Sun Microsystems, Inc., Java 
platform for sending and receiving maiL A set of 
abstract APIs that model a mail system, JavaMail pro- 
vides a platform-independent and protocol-independent 
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page layout n. In desktop publishing, the process of 
arranging text and" graphics on the pages of a document. 
Page-layout programs excel in text placement and man^ 
agement of special effects applied to text. Although page- 
layout programs are generally slower than word -processing 
programs, they can perform such advanced tasks as flowing 
text into complex mukicoluron page designs, printing de*> 
uments in signatures, managing color separations, and sup- 
porting sophisticated kerning and hyphenation. 

page makeup n . The assembling of graphics and text on 
a page in preparation for printing, 

page mode RAM n. A specially designed dynamic RAM 
that supports access to sequential memory locations with a 
reduced cycle time. This is especially attractive in video 
RAM r in which each location is accessed in ascending 
order to create the screen image. Page mode RAM can 
also improve the execution speed of code because code 
tends to execute sequentially through memory. See also 
cycle time, dynamic RAM. 

page orientation n. See landscape mode, portrait mode, 
page printer n. Any printer, such as a laser printer, that 
prints an entire page at once. Because page printers must 
store the entire page in memory before printing, they 
require relatively large amounts of memory. Compare line 
printer, 

pager n. Pocket-sized wireless electronic device that uses 
radio signals to record incoming phone numbers or short 
text messages. Some pagers allow users to send messages 
as welL Also called: beeper. 

page reader «. See document reader, 
page setup ?i. A set of choices that affect how a file is 
printed on the page. Page setup might reflect the size of 
paper going into the printer, the page margins, the specific 
pages in the document to be printed, whether the image is 
to be reduced or enlarged when printed, and whether 
another file is to be printed immediately after the first file 
is printed. 

pages per minute n. See PPM. 

Page Up key n, A standard key (often labeled "PgUp") 
on most computer keyboards whose specific meaning is 
different in different programs. In many cases, it moves 
the cursor up to Che top of the previous page or a specific 
number of lines. 



pagination n. J. The process of dividing a 
pages for printing. 2. The process of adding j| 
bers, as in a running head. 



paging n. A technique for implementing viu t 
The virtual address space is divided into a mi 
fixed-size blocks called pages, each of which 1 ! 
mapped onto any of the physical addresses ava. 
the system. Special memory management hardL 
(MMU or PMMU) performs the address uajislaL, 
virtual addresses to physical addresses. See 
management unit paged memory management ^ 
tuai memory. 

paging file n. A hidden fde on the hard disk thafic 
ing systems (such as Windows, Mac OS X, and'C 
use to hold parts of programs and data flies that dj| 
in memory. The paging file and physical memor^f 
RAM, make up virtual memory. Data is moved fn" 
paging file to memory as needed and moved fronti^ 
to the paging file to make room for new data in mel 
Also called; swap file. See also virtual memory, 
paint* n, A color and pattern used with graphics pnSj 
to fill areas of a drawing, applied with tools such as! 
paintbrush or a spraycan. 

paint 2 vb. To fill a portion of a drawing with paint (t 
or a pattern). 

paintbrush n. An artist's tool in a p^int program or 
another graphics application for applying a streak of $ 
color to an image. The user can usually select the w' 
the streak. See also paint program. Compare sprayc 
paint program n. An application program that crea& 
graphics as bit maps. A paint program, because it „_ 
drawing as a group of dots, is particularly appropriate „ 
freehand drawing. Such a program common Jy provides^ 
tools for images requiring lines, curves, and geometric 
shapes but does not treai any shape as an entity that can U 
moved or modified as a discrete object without losing its" 
identity. Compare drawing program. 

palette n. 1. In paint programs, a collection of drawing „ 
tools, such as patterns, colors, brush shapes, and different- 
line widths, from which the user can choose. 2, A subset : 
of the color look-up table that establishes the colors that 
can be displayed on the screen at a particular time. The 
number of colors in a palette is determined by the number 
of bits used to represent a pixel. See also color bits, color 
look-up [able, pixel. 
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METHOD AND SYSTEM FOR CREATING 
AND SENDING GRAPHICAL EMAIL 

This U.S, patent application claims Ihe priority of U.S. 
Provisional Application No. 60/159,636 filed on Oct. 13, 5 
1999, entitled "Graphical Email Drawing and File Attach- 
ment System", by the same inventor. 

FIELD OF THE INVENTION 

Hiis invention relates generally to the processing of 10 
handwritten content as digital data in electronic messaging, 
and specifically to an electronic messaging system for 
graphical (handwritten or handdrawn) email. 

BACKGROUND OF THE INVENTION 35 

Electronic messaging is a general method for sending and 
receiving communications as digital data between comput- 
ers on a network. The Internet has dramatically increased 
electronic messaging amongst millions of users on global 20 
data networks. Many different forms of electronic messag- 
ing are being used lo send and receive communications in a 
wide variety of forms of structured and unstructured data. 
Businesses make extensive use of electronic messaging to 
conduct business communications and transactions between 2 5 
trading partners. Electronic mail (or email) is a popular form 
of electronic messaging for communications between users. 
Typical email messages are composed of typed texl or a 
combination of typed text and text or graphical files that are 
attached to the email message and opened wiih the appro- 30 
priate processor or viewer. As the popularity of the Internet 
continues to grow worldwide, more and more people num- 
bering in the billions are expected to use email for commu- 
nications. 

Recent advances in technology and standards have 35 
expanded the types and forms of devices that can conned to 
the Interact. In addition to dial-up and online connections 
between users computers and servers that provide informa- 
tion services and email services, many types of other devices 
are being connected to the Internet for communications oq 
purposes, including personal digital assistants (PDAs), 
messaging pagers, digital cellphones enabled with Wireless 
Application Protocol (WAP) ? advanced digital game 
machines, digital set lop boxes for televisions, and even 
CPU -controlled household appliances. Many of these 45 
devices having Internet access do not require or are not 
adapted to use a keyboard for inputting data. While there are 
other types of input devices that enable handwritten or 
handdrawn input, such as touch sensitive screens, stylus 
pads, optical pens, etc., they have not been enabled for 
electronic messaging and other communication functions. 

Handwritten or handdrawn input can be more convenient 
to use than a keyboard and, in many situations, would be 
uniquely necessary for certain types of communication. 
Many written language systems, such as Japanese, Korean, 
Chinese, Arabic, Thai, Sanskrit, etc., use cursive or ideo- 
graphic characters that are very difficult to input by an 
equivalent method via keyboard. For example, text input of 
the Japanese written language requires the use of simulated 
phonetic spelling methods (romanji, biragana, and/or 
katakana) to select from thousands of possible kanji char- 
acters. Many mobile devices such as PDAs do not have 
keyboards due to their Hmited size and form, or would 
become cumbersome to use if a keyboard must be aUached 
or if text must be entered by cursoring through displays of 
softkeys. Disabled or hospitalized people who have limited 
hand mobility may no! be able to use a keyboard effectively. 
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Current legal and financial institutions still rely heavily on 
the use of handwritten signatures to validate a person's 
unique identity. And in many instances, people find it much 
easier to communicate an idea by drawing a picture, or 
prefer handwriting or drawing a picture as more personal or 
expressive communication than typing text on a keyboard- 
There is thus a clear need for an electronic messaging 
system that allows people to communicate with their own 
handwriting or drawing, as contrasted to typed text. This 
need will continue to grow as the numbers of global users 
and Internet-connected devices increase. None of the current 
electronic messaging methods allow a user to compose, 
manipulate^ store, send, receive, and view a handwritten or 
handdrawn email message. 

SUMMARY OF THE INVENTION 

In accordance with the present invention, an electronic 
messaging system, and related method, comprises a hand- 
writing server component operable on a server computer on 
a network with an email host server for receiving an email 
message sent from a user and storing it for retrieval by a user 
to whom it is addressed, and a handwriting client component 
operable with an email client on a client computer for setting 
up a graphical data capture area into which a user can enter 
handwritten or handdrawn input through a suitable graphical 
input device, and far capturing the handwritten or hand- 
drawn input as graphical data and sending it via the network 
to the server component for handling as an email message. 
The clienl component is also operable for setting up a 
graphical data viewing area for viewing the graphical data 
sent with an email message handled by the server compo- 
nent. 

In another version of the invention, an electronic mes* 
saging device, and related method, comprises a handwriting 
messaging component operable in a web browser of a 
computer connected on a network for setting up a graphical 
data capture area into whicb a user can enter handwritten or 
handdrawn input through a suitable graphical input device, 
and for capturing the handwritten or handdrawn input as 
graphical data and sending it as an email message on the 
network. The handwriting messaging component can con- 
vert the graphical data to a GIF file that is attached to the 
email message and send the email message to a standard 
Internet email server. Alternatively, the handwriting mes- 
saging component can format the captured data as pixel data 
and send it to a handwriting server component of a server 
computer that can transmit it to a receiving computer 
enabled with a similar handwriting messaging componeol 
for retrieving the email message and viewing the pixel data 
as the corresponding handwritten or handdrawn image, 

la the preferred embodiments* the handwriting messaging 
component is a Java applet downloadable to a web page for 
an email client of a standard web browser, or may be a Java 
55 plug-in application installed with the web browser, The 
graphical input device can be a touch screen, pen input 
device, stylus pad ? or even a standard mouse. The handwrit- 
ing messaging component sets up a drawing editor/viewer 
thai allows the user to compose, manipulate, and view 
6£} handwritten or handdrawn messages. The editor/viewer can 
include standard drawing tools such as those for line size, 
color, paper and border selection, circle and polygon shapes, 
spray paim ? Hood fill, color palette, undo and scrolling 
functions. 

65 Other objects, features, and advantages of the present 
invention will be described in further detail below, with 
reference to the following drawings: 
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BRIEF DESCRIPTION OF DRAWINGS 

FIG, 1A is a diagram illustrating the connection of client 
computers with pen devices to an email server computer on 
the Internet, and FIG. IB shows the email handling com- 
ponents of the client and server computers; 

FIG. 2A is a process flow diagram of an SMTP server 
version of the graphical email system, and FIG, 2B is a 
schematic illustration of the network connections of this 
version of the graphical email system; 

FIG. 3A is a process flow diagram of a Lotus™ Domino 
server version of the graphical email system, and FIG. 3B is 
a schematic illustration of the network connections of this 
version of the graphical email system; 

FIG. 4A is a process flow diagram of a real-time mes- 
saging server version of the graphical email system, and 
FIG. 4B is a schematic illustrations of the network connec- 
tions of this version of the graphical email system; 

FIG. 5 is a schematic illustration of the network connec- 
tions of an Interne! email server version of the graphical 
email system; 

FIG. 6 is a schematic illustration of the network connec- 
tions of a WAP-enabied cellphone or PDA version of the 
graphical email system; and 

FIG. 7 A is a schematic illustration of the user interface for 
the graphical data capture and drawing functions of the 
graphical email system; and FIG. 7B is an example of an 
editor/viewer interface for the graphical email system on a 
personal digital assistant (PDA). 

DETAILED DESCRIPTION OF INVENTION 

Referring to FIG. 1A, the general system architecture of 
the graphical email system (and related method) of the 
present invention is illustrated. A plurality of client comput- 
ers 11 0> 111* etc., adapted for handwriting or haoddrawing 
input are used by users to connect via a network (the Internet 
or any type of multi-user network) to a server computer 120, 
In the context of this description, the term "computer" is 
used to refer to any type of data processing device which is 
capable of executing digitally programmed instructions. The 
term "client computer" refers to any computer capable of 
connecting to a server computer on a network and perform- 
ing a function with the server computer. An example of a 
typical computer for use on a network is a Pentium or higher 
class PC with Windows operating system of Microsoft 
Corp., Redmond, Wash., or Macintosh or higher class PC 
with Macintosh OS operating system of Apple Computer 
Corp,, Cupertino, Calif, However, a client computer can also 
be a wide range of other network-connect able computing 
devices such as personal digital assistants (PDAs), text 
messaging pagers, digital cellphones enabled with Wireless 
Application Protocol (WAP)* advanced digital game 
machines^ digital set top boxes for televisions, and even 
CPU-controlled household appliances. The term ''server 
computer" is used to refer lo any type of data processing 
device that is connected to a node on a network for providing 
services to client devices on the network. 

In the present invention, the client computer HO is what 
a sender or recipient uses to compose and send, and receive < 
and viewj handwritten or handdrawn email messages. The 
client computer preferably is of the type that can run a 
standard web browser which supports an email client, such 
as those compatible with Microsoft IE 4.x browsers, 
licensed by Microsoft Corp., of Bellevue, Wash.^ or * 
Netscape 4.x web browsers, licensed by America Online, 
Inc., of Fairfax, Va, The standard browsers preferably also 
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support the Java Virtual Machine* Version 1.2 or higher, 
licensed by Sun Microsystems, of Mountain View, Calif., 
which is the preferred platform for programming and dis- 
tributing the handwriting messaging software in the present 

5 invention as Java applets or Java-based plug-ins to the 
browsers. The standard web browsers connect to the net- 
work using any standard protocol recognized on the net- 
work. For example, on the Internet standard web browsers 
use the TCP/IP protocol. Connection to the network may be 

30 made by modem over a dial-up telephone line, DSL line, 
cable modem ? Internet access connection, or a local area 
network. 

The handwriting or handdrawing input device can be a 
touch screen, pen input device, stylus pad r optical pointer, 
j 5 mouse, etc., which is attached to the client computer lo allow 
the user to handwrite or handdrawn messages in a graphical 
data capture area of the email client of the web browser set 
up for that purpose. Examples of such input devices include 
the Wacom Graphire™ pen tablet sold by Wacom Technol- 
iq °gy Corporation* of Seattle* Wash., which attaches to the 
client computer via a serial or USB port. The pen device 
could also be integrated with a touch screen, e.g., as also 
offered by Wacom, or part of the computer itself, e.g., as 
offered with the Sharp SJ5, Copernicus and Pro Stations sold 
t5 by Sharp Corporation, of Tokyo, Japan. 

The server computer is a central processing server for the 
graphical email system. It is connected to the network to 
communicate with the client computers using, for example, 
the TCP/IP protocol on the Internet, In the preferred 

30 implementation, the server computer stores the graphical 
email handling software that is downloaded to the client 
computers. It authenticates users against a directory of 
authorized users and manages and tracks the state of con- 
current user sessions. For sending and receiving graphical 

35 email, it communicates with the graphical email software on 
the client computers. When a handwriting message is com- 
posed on the client computer, the server computer receives 
the graphical email message and stores it in a database. 
When a handwriting message is to be viewed by the client 

43 computer, the server computer fetches the graphical email 
message from the database and sends the message to the 
client computer for display as a handwriting image. 

Referring to FIG. IB, the graphical email handling com- 
ponents of the preferred implementation of the invention 

45 system are illustrated. The client computer 210 includes a 
Handwriting Messaging Client 211 which handles sending 
and receiving graphical email messages, a Java Virtual 
Machine (VM) 212 which sets up the graphical data capture 
area and display area for the handwriting message, and the 

so Web Browser 213 which provides the user interface for 
connecting to the Internet (or other network). There are two 
versions of the Handwriting Messaging Client software 
described below, i.e., a Java applet and a Java application 
version. The Java applet version is used for sending and 

55 receiving handwritten email messages via a server comput- 
er's mail server functions. The Java application version of 
the handwriting messaging client software is installed with 
the users* browsers for real-time messaging between users 
or via a real-time Java server. The client software includes 

so a drawing editor/viewer for composing and viewing hand- 
written email messages, as well as the functions to commu- 
nicate with a server in a server-client configuration. 

Hie server computer 220 includes an HTTP Server Inter- 
face 221 for connection to the Internet, a User Directory 222 

55 for identifying email addresses of authorized users, User 
Message Queues 223 for delivering received messages to 
users, a Downloadable Software Server 224 for download- 
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ing the graphical email software to client computers, a Mail 
Server Interface 225 for handling sent and received email, a 
Java "virtual Machine (VM) 226 which provides the platform 
for interacting with the users* graphical email software, and 
a Handwriting Messaging Server 227 which formats email 
messages using the graphical data captured by the software 
on the clienL computers. There are four versions of the 
Handwriting Messaging Server described below, i.e, ? a 
Handwriting Java Server Version, a Domino Server Version, 
a Real-Time Java Server Version, and an Internet Email 
Server Version. 

Handwriiing Java Client and Handwriting Java Server Ver- 
sion 

With reference to FIG. 2B, this version of the system uses 
both handwriting client and server software components 
along with the usual email server functions, A Handwriting 
Java Client 210a operates in a web browser (such as 
Netscape Navigator or Microsoft Interne! Explorer) as a 
Java applet on the client computer 210. The applet 21 0g 
provides a drawing editor lo compose and send handwritten 
email messages, and on the receiving end, also provides the 
drawing viewer to view the handwritten message. The 
implementation of a Java applet for the handwriting mes- 
saging function is described in further detail below. 
Generally, the use of a Java applet to provide a drawing 
application intended to run in a browser is known to those 
knowledgeable in this field. As one example, a Java applet 
used to set up a drawing editor in a browser for a "white™ 
board 1 ' application run on an intranet is the SameTime™ 
whiteboard applet offered with Lotus™ Notes, a workgroup 
software suite distributed by Lotus Development Corp., of 
Cambridge, Mass., which is a division of IBM Corp., 
Arrnoak, N.Y. 

In the present invention, a Java applet is created specifi- 
cally for setting up a drawing editor/viewer operable with an 
email client running with a web browser for capturing, 
sending, receiving and viewing a handwriting of handdraw- 
ing email message. The Java applet consists of a set of 
modules which run the different messaging functions of the 
drawing editor/viewer. The data capture and sending module 
operates by first recognizing the handwriting input device 
connected to the clienL computer, then creating a temporary 
memory space for holding the input received from the input 
device, capturing the input signals from the input device 
(usually a series of coordinate data inputs representing 
time-sampled coordinate positions detected for the trace of 
the inpul device), converting the input signals lo pixel data 
(screen coordinates, color, intensity), and displaying the 
pixel data in a display area or "panel" of the email client to 
show the handwriting or banddrawn image input by the user 
through the inpm device. The display allows ihe user send- 
ing a handwritten email message to verify what is being 
written, aod is also the same display that allows a user 
receiving the handwritten email message to view the corre- 
sponding image. An example of a data capture and sending 
module according to the invention is illustrated in the source 
code listing appended hereto as Appendix L 

When the graphical email message is completed, the user 
addresses the message to a recipient and sends it. The 
Handwriting Java Client formats and sends Ihe email mes- 
sage with the pixel data to the Handwriting Java Server 
component 220# on the server computer 220, which con- 
verts tbe pixel data to a GIF file attachment to a standard 
email body. The Handwriting Java Server component 220# 
communicates with an SMTP email gateway computer 240 
lo send email messages using the industry-standard SMTP 
Internet protocol. The SMTP email gateway sends the email 



40 



50 7, 



ss 



65 



messages to mail servers 2S0 S such as an industry-standard 
IMAP (Internet Message Access Protocol) mail servers like 
MS Exchange or Lotus Domino on the Internet. Email 
recipients can retrieve their email from the mail servers 250 
using a standard Internet email client 260, such as Microsoft 
Outlook, Pegasus Mail, Eudora mail, or Lotus Notes. When 
the graphical email is retrieved with a standard Internet 
email client, the handwritten drawing is viewed as a file 
attachment using a GIF viewer operates with the web 
browser. Email recipients on client computers 230 who have 
ihe Handwriting Java Client 21©a in their web browser can 
receive their handwritten email messages directly. The 
graphical email message is retrieved from tbe Handwriting 
Java Server component 220a on the server comp-uter 220 
and displayed in the Handwriting Java Client viewer as a 
handwritten or handdrawn image. 

With reference to FIG. 2A, the specific process steps 
involved with sending a handwritten email message and 
viewing it by the recipient are described in detail below; 
L The Handwriting Java Client software is downloaded 
from the Handwriting Java Server to the client computer 
through a web page that is displayed in a web browser. 
2. The Handwriting Java Client software is initialized and 
establishes a connection to the Handwriting Java Server 
using Ihe industry-standard TCP/IP and remote method 
invocation (RMI) protocols. After initialization is 
complete, the Handwriting Java Client software displays 
a drawing composition editor that is used lo compose the 
handwritten message. 

The handwritten message is composed by the user in a 
graphical data capture area set up by the drawing editor, 
selecting the appropriate writing and drawing tools, 
colors, and styles as offered in the Handwriting Java 
Client software. 

4. While the user is drawing in the graphical data capture 
area, the pixel data representing the drawing is stored in 
local memory. When the graphical email message is 
completed* the user addresses the message to a recipient 
using Javascript fields on the web page in which the Java 
handwriting client is embedded. 

5. When the user issues a "Send" command, the Handwriting 
Java Client formats the message and sends the pixel data 
to the Handwriting Java Server. Tbe graphical message is 
still in GIF formal at this time. 

6. The Handwriting Java Server processes the graphical 
message data using standard base&4 encoding. This turns 
the data into ASCII text that can be transmitted as 
standard email data packets by the Handwriting Java 
Server. 

The Handwriting Java Server creates an outgoing email 
message thai contains the encoded handwritten message 
as a GIF attachment. 
8* The Handwriting Java Server sends the outgoing email 
message with GIF attachment via the SMTP (Simple Mail 
Transfer Protocol) gateway 24€. 
9, The SMTP gateway transfers the message to an IMAP 
mail server based on the recipient's address. The IMAP 
server allows clients running it to retrieve mail from the 
host mail server also running the protocol* similar to 
POP-3, but with extended capabilities. Recipients can 
open the email as a standard email message with a GIF 
attachment (steps 10a, 10b below) or with a Handwriting 
Java Client applet if downloaded to their web browser 
(steps 11a, lib, 11c below). 
10a. The IMAP server sends the email with the handwritten 
message as an attached encoded GIF file to an external 
email address for the recipient. 
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10b. When the recipient opens the email containing the 
attachment the message cao be displayed os their com- 
puter using a GIF viewer. 

11a. The IMAP server sends the email with the handwritten 
message as an atlached encoded GIF file to ae internal 
email address, i.e., to an address on a server computer 220 
that is running the Handwriting Java Server component 

lib. The Handwriting Java Server decodes the attached GIF 
file into pixel data and sepds U to the Handwriting Java 
Client applet running in the recipients web browser. 
11c, The Handwriting Java Client receives the pixel data 
from the Handwriting Java Server and renders the pixel 
data as a handwritten or banddrawn image m the drawing 
editor/viewer. 
Handwriting Java Client and Domino Server Version 

With reference to FIG. 3B, this version of the system uses 
the Handwriting Java Client 310c? along with a Lotus™ 
Domino Server od the server computer 320 T As before, the 
Handwriting Java Client 310a operates in a web browser as 
a Java apple! on the client computers 310,330. The applet 
310tf provides a drawing editor/viewer to compose and view 
handwritten messages, For sending and receiving email 
internally, the applet 310# communicates with the Domino 
Server on the server computer 320. The Domino server 
sends email messages among users with client computers 
running Java client software connected to the server's intra- 
net. The Domino Server communicates with an SMTP email 
gateway computer 340 to send email messages externally 
using the SMTP Internet protocol. The SMTP email gateway 
sends the email messages to mail servers 350 ou the Internet. 
External email recipients can retrieve their graphical email 
using a standard Internet email client 360. The handwritten 
drawing can then be viewed as a file attachment using a GIF 
viewer such as a web browser. 

With reference to FIG. 3 A, the process steps involved 
with sending a handwritten email message through a 
Domino Server and viewing it by the recipient are described 
in detail below: 

1. The Handwriting Java Client software is downloaded 
from the Handwriting Java Server to the client computer 
through a web page that is displayed in a web browser. 

2. The Handwriting Java Client software is initialized and 
establishes a connection to the handwriting Domino 
Server Rising the TCP/IP and remote method invocation 
(RMI) protocols. After initialization is complete, the > 
Handwriting Java Client software displays a composition 
editor that is used to compose the handwritten message. 

3. The handwritten message is composed by the user select- 
ing the appropriate writing and drawing tools, colors, and 
s!yles. 

4. While the user is drawing, the pixel data representing the 
drawing is captured in the input data, area and stored in 
local memory. The user addresses the email message to a 
recipient using Javascript fields on the web page in which 
the Handwriting Java Client is embedded, 

5. When the "Send" command is issued, the Handwriting 
Java Client encodes the pixel data in base64 format. 

6. Hie Web page along with the encoded image is posted to 
the Domino Server using Javascript. 

7. An agent on the Domino Server decodes the image and 
creates an email message with an attached GIF file. 

8. The Domino server sends the email message with attach- 
ment to an external recipient's address via an SMTP 
(Simple Mail Transfer Protocol) gateway. 

9. The SMTP gateway transfers the email message to a mail 
server, which routes the message to the reeipicot's email 
box. 
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10a. an external recipient's e-mail client retrieves the email 
message with the GIF attachment from an Internet email 
server, 

1Gb. Wheo the user (recipient of the email) opens the email 
containing the GIF attachment, the handwritten message 
in the attachment can be displayed using a GIF viewer. 
11a. If the recipient has an internal email address handled by 
a Domino Server, the server retrieves the email message 
with the GIF attachment, 
lib. The Domino Server sends the email message to the 
client computer as a web page when the client requests the 
page via their web browser email client. 
11c, The client's web browser email client displays the 

handwriuen message as an image 
Handwriting Java Ciierit and Reai Time Server Version 

With reference to FIG. 4B> this version of the system uses 
the Handwritiog Java Client with a Real Time Handwriting 
Java Server. As before, the Handwriting Java Clieet 410a 
operates in a web browser as a Java applet on the client 
computer 410,. 430. The applet 41 Ga provides a drawing 
editor/viewer to compose and view handwritten messages. 
The applet 410a communicates with the Real Time Java 
Server component 420a on a server computer 420. The 
receiving Handwriting Java Client is notified when m email 
message for that user has been sent to the Real Time Java 
Server, and retrieves the email message from the server. In 
this way, communication can take place using the Hand- 
writing Java Client m near real-time. This version is useful 
for users using mobile communication devices, such as 
PDAs, WAP-p hones, etc. 

With reference to FIG, 4 A, the process steps involved 
with sending a handwritten message through a Real-Time 
Handwriting Java Server and and viewing it by the recipient 
are described in detail below: 

1. The client computer has a downloaded version of the 
Handwriting Java Client software, and establishes a con- 
nection with the server computer on which the Real Time 
Java Handwriting Server is running. 

2. The client computer identifies the user to the server by 
entering a user name and password. 

3. The server maintains a list of registered users, and a list 
of currently active users. When the client logs onto the 
server, the server looks up the user name and password in 
order to authenticate that person as a registered user, then 
the user is added to the list of active users, 
The client computer displays a list of active and inactive 
users which is downloaded from the server. 
The user clicks on a name from the list of active users to 
identity the user to whom they want lo send a message. 
After the user selects a name from the list of active users, 
the handwriting editor is displayed in the Handwriting 
Java Client. 

7, Hie user creates a message by selecting the appropriate 
writing and drawing tools, colors, and styles. 

S. The Handwriting Java Client formats the message and 
stores it as pixel data until it is ready to be sent. 

9. The completed message is sent to the Real Time Java 
Handwriting Server in pixel format. 

10. The server receives the message and puts it kilo a 
repository where it can be retrieved by the user to whom 
it is addressed. 

11. AO active client computers poll me repository on the 
server every five seconds to see if there are any messages 
for ihem. 

12. When the Handwriting Java Client on the recipient's 
computer discovers a message in the repository, the ciiem 
computer requests the message from the server 
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13, "The server retrieves the message from the repository and 
sends it to the client computer of the recipient. 

14. The recipient's client computer displays the message ia 
the Handwriting Java Client's drawing editor/viewer. 

Handwriting Java Client and Internet Email Server Version 
With reference to FIG. 5, this version of the system uses 
the Handwriting Java Client along with a standard Internet 
email mail server. In this version, the Handwriting Java 
Client is installed as a plug-in to the client computer's web 
browser and operates as described before, and there is no 
Handwriting Java Server component. The Handwriting Java 
Client 510a operates in a web browser as an installed Java 
applet on the client computer 510. The apple! 510(2 provides 
a drawing editor/viewer to compose and view haodwritteri 
messages. The Handwriting Java Client formats the message 
and stores it as pixel data until it is ready to be sent. The 
message is addressed using Javascript fields on the Web 
browser form in which the Java applet is embedded- The 
pixel image is converted into a GIF file and attached to the 
email message. The Java applet SlOa com mimic ales with the 
Mail Server computer 540 either directly or through as 
SMTP gateway computer 520, The Mail Server 540 sends 
the email message with encapsulated GIF image directly to 
the recipient's cheat computer 530, and the recipient views 
the attached GIF file using whatever GIF viewer they have 
available on their computer. 25 
Handwriting Java Client and Wireless Internet Email Server 
Version 

With reference to FIG, 6, this version of the system uses 
the Handwriting Java Client along with a standard Internet 
email mail server providing email service to wireless client 30 
computers, such as WAP-pbooes and PDAs. As before, the 
Handwriting Java Cliem 610a operates in a web browser as 
an installed Java applet on the client computer 610. The 
email message is formatted with the handwritten image 
converted into an attached GIF file. The Java applet 610a 
communicates with the Mail Server computer 640 either 
directly or through an SMTP gateway computer 620, The 
Mail Server 640 includes a Wireless Application Protocol 
(WAP) interface which sends the email message with encap- 
sulated GIF image through a Wireless Service Provider 
having WAP handling capability to the recipient. 40 

The recipient's computer can be a thin client 630a such as 
a digital cellphone with a WAP interface for receiving the 
email message via Internet and displaying the GIF file via its 
mini -web browser. Alternatively, the client computer may be 
a more robust, mobile client computer 630b such as a Palm 45 
Ptiois or similar type of PDA* which has the memory and 
CPU capacity to have a Handwriting Java Client installed 
with its web browser and use it for composing and sending 
handwriting email messages as well as viewing them. The 
mobile client computer can then use the Handwriting Java 50 
Client to formal the handwritten message as an attached GIF 
file (described in the Internet Email Server version) or as 
pixel data sent with the email for viewing by another client 
computer having a Handwriting Java Clieol running in its 
web browser (as described in the Real-Time Server version). 55 

A handwriting messaging application written for a palm- 
top or PDA device would currently have to be written in C 
or C++ because there are no current Java Virtual Machine 
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adaptations that can be used for such devices. However, 
several efforts are underway to create such Java VM mod- 
ules for palm-lop and PDA devices. Using C/C++ to write 
full applications on paim-top devices has the current adv&a- 
5 tage that the security sandbox imposed on Java applets does 
not exist, thereby allowing a wider variety of messaging 
applications to be written, as long as actual implementations 
are kept simple (due to low CPU power and memory storage 
availability). The handwriting client can be kept simple by 
including only pen and eraser tools and different line thiek- 
jo oesses. Only palm-top devices with color displays would 
need a color palette; black and white palm -top devices 
would dither incoming messages to black and while while 
sending only two-color images. Sioce the client is written in 
C or C++, networking would be limited to standard TCP/IP 
communications instead of Java's RMI, For communica- 
tions through a proxy, packets can be wrapped in HTTP and 
sent through an HTTP proxy. If a handwriting server com- 
ponent is used with the palm-top devices, it would remain 
largely the same as described above, except that it would 
handle only standard TCP/IP communications, and would 
add the ability to receive messaging information wrapped in 
HTTP packets from behind a firewall. 

The functions of the module of the client component 
which con veils and sends the handwritten message for 
handling as an email message depends upon the configura- 
tion of the system. If the system is configured with a Lotus 
Domino server on a Java VM platform, then the captured 
handwriting data is sent as a message to the Domino server 
in the form of a stream of pixel data which is converted by 
the server to a Graphics Interface Format (GIF) file and 
appended with an email header to form an email message 
handled by the server's email service. If the system is 
configured with a standard type of Internet email server, then 
the captured handwriting data can be converted at the client 
computer to a GIF file and sem as an email message to the 
Internet email server. If the system is configured for real 
time messaging between client devices, the client device can 
send the handwritten message as a GIF file appended lo 
standard email, or send it as pixel data to a real-time 
messaging server which provides real-time messaging ser- 
vice between client devices. 

In FIG. 7 A, the user interface for the drawing editor/ 
viewer of the Handwriting Java Client is illustrated. For 
composing a handwritten message, the editor/viewer 710 
has a graphical data capture area 720 in which handwritten 
input can be entered with a touch pen or on a stylus pad and 
captured as pixel data. The editor/viewer 710 can offer a 
suite of standard types of drawing tools such as making line, 
circle* or polygon shapes and spraying and filling image 
areas. The graphical data capture area 720 is also the 
graphical image viewing area for email received with an 
attached GIF file or pixel data. In FIG. 7B f a typical layout 
for a PDA of the editor/viewer interface with drawing tools 
and color palette is illustrated. 

It is understood that many other modifications and varia- 
tions may be devised given the above description of the 
principles of the invention- It is intended that all such 
modifications and variations be considered as within the 
spirit and scope of this invention, as defined in the following 
claims. 
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GRAPHICS DATA CAPTURE & SENDING MODULE 



import java/utiL"; 
import iavax.mail.'*; 
import j&vax.activstioiL*; 
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APPENDIX I-coniimied 



GRAPHICS DATA CAPTURE & SENDING MODULE 



import javax. mail, internet.*; 

r* 

* StarMaitAgent is called as the form action for a starmail submission form 

* (see, for example, pages/starmailmessage) 

* Note that U is noi a web query &avc agent! 
V 

public class StarM&itAgent extends RttpAgentBase 
{ 

pioiteeied Session ai_..mailS=ssion; 
protected SLring m„sUrHoirt; 
protected String m^strSlvfrF; 
protected Siring m_„$trUser; 
protected String _ti_.strF&sswoTd; 
protected Si ring rjL__stf Admin; 
protected boolean m__bFiKcred; 

r m 

* Mam entry poult for ihia agent 

- THIS IS THE MAIN EMAIL DELIVERY CODE 

'/ 

public void doPmt(HttpAgcnmequesl: _req, HttpAgentRespoase _res) { 
// Get mail parameters 
String protocol - "imap* 1 ^ 
m_StiHost - _req.ge^rverNams( ); 

m_„str5MTP « _req,geiParamctei("SMlTServer"); 
m strUser * _^cq.getPa^ametc^(* i FTom T, ); 
ju_sttPassword = „req.getPa.rameteF(" Password"); 
m....sti Admin = ^req-geLParameier^AdrniE 1 '); 
_n_b Fii tered = __req ,getPa nuneier(" Fil teied' eqttJiU<" Yes"); 
// Establish mail properties and gel a session 
Properties props *» new Propertied); 
pfops T put( ,UL mai].iraap-hosr 3 m^strHost); 
praps.putf^maiJ.simtpJjc&t", ro_stiSMTP); 
m__mailSe&sjoTi » Session^ _De fe_ lrlnstasce (props, null); 
// Get maU pa rams 

Suing strTo - _req.getPararneter{* + SendTb"); 
String strSubj * _feq.geiParameter("Sttbjeci*'); 
String strBody - _req.getP&rBrneter( 4J Body J '); 
Stri ng strl mage - „req . getPst mmeter (" I m & ge ") ; 
// create and send the irsessage 
try { 

Message msg; 

if (sti Image »** atill) { 

// Create and send message* and append to the outbeoc 
msg *= create Message (strTti* strSubj, str Body); 

} else { 

rrtsg - createlmageMessage^trTo, sirSubj, sirBody, strlmags); 

} 

Trausport.5eiid(msg); 

if (_req.getParameier( H Ssve te },equiil5£~Yes")) { 
append Message (m$g, "ouibojO; 

} caicb (MessagirjgEjtceptiOTi e) { 

„res .setCon Eei^Ty pe(** Lexl,>p]aiD")^ 
FrintWriter out * „res.ge£Wriicr( ); 

ouLp ri nil n{Bi_strHcst) ■ 
e,t>rkttStackTracc(o^ iy t 

} 

// Redirect to in box 

String path « _feq,getPa£hlnfo< ); 

String shortpatn = patLsubsiring^O, patkbade:xOf{ H .-sf"))-, 
shortpath «■ shortpath.sub$:ring(0 ? path.ifldesOfCT^ + 3); 

__res.se £idRedirect(£hortpatb + ^req.getparameter^MaiJDB") + 

// 

"/SInbox"); 

_re5,5endRediieci(shortp&tli + ..req.getParairieterCurl' 7 }}; 

} 

r~ 

* Given some text, create a mail message atst of it suitable for mailing 

* @param to 

* <§Jparam „_sub| 

* @param _tcxt The message body text 

"/ . 

protected Message cre_teMes£age(S&nng _to, String _iubj*, String __text) 
throws MessagingExcepiioa { 

Message msg - iiew MimeMessage(m_inaiiSessioii); 
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APPENDIX I -continued 



GRAPHICS DATA CAPTURE & SENDING MODULE 



InterneiAd dress fromAddr - create Address (m„*trUser); 
rrtsg^etFro in (f ram Addr); 

InierBttAddress[ ] recip *> new InternetAddressfi]; 
Strirjg subject; 
if (m_bRltered) { 

recip[Q] « create Add TesE('m strAdmin); 

subjsct - ^jsvbj + * _ta; 

} else { 

recip[0] - cr eatcAddTess( to); 

subject = _jsubj; 

} 

m£g^etRccipka££{McfSsage.R«cip«mType.TO > recip); 
msg,setSub}ec t(5iibj ect) ; 
ni£g.s«Coritent(__text J "text/plam"): 
return tnsg; 

I 

/** 

* Given some tsxt, create a mail message oue of ii suitable for meiJiag 

* (rSperam 

* @param sub] 

* @psram _iext The message body text 

* @param „image The image daXx r encoded as Base 64 
"7 

proiecied Message cieawtmageMessagefStriiig _£c, String _5ubj> String 

String image) throws MessagingEjiceptiEon { 

Message msg &ew MiimeMessage{m_nriailSessioa)- 
IntcrceLAddicss fromAddr =*= createAddress (m^strUser); 
msg^etFrom (fromAddr); 

EnicniClAddressf ] recip new IsterBetAddressIl j; 

String subject; 

if (m_bFillered) { 

rccipJG] » cre&te Address (m_sirAdm is); 

subject - __subj + + 
} else f 

recip[0] p- cfeateAddressC^to); 
subject * _subj; 

1 

msgietRecipients(Mc5SSgfi.RficipientType,TOj recip); 
msg j&etSuhject(subjeci) ; 
// Add the tew psrt 

Mu liipart mp ™ new Mijr*eMuMpa:rt( ); 
MimeBodyPart bodyl new !MimeBodyFar£( ); 
body 1 .5e£Text(__tcxt) ; 
mp.add Bod yPaft(body 1) ; 
y/Add the attachment 

MimeBodyPart body2 » new MirneBodyPart( ); 

bytal ] data « Base 64Decoder, decode (_unage.toCh&rArr&y( )); 

body2-setDataH5fidler(aew DataHsndleT(data, "image/gif")); 

body2,setFiieN&me("StarMaiLgif'); 

mp.addBodyPari(b0dy2); 

msg ,£etCDntent(Ti!p); 

return cisg; 

} 

/•* 

* Create aft Inter act address from this string. Basics Hy searches for 
end fippenrls 

* "^hostname* 1 " if not found 
V 

protected InlersetAddress creatsAddress(Stririg „addr) Lbrows 
Address&e caption { 

if („addr.indexOfr w @") — -1) 

_addr +- "@" + rtx_strHost; 
return new Interne tAd dress ( sddt); 

1 

/*- 

" Append the message to the given Colder 

* ig>parain .. msg The message iq sppead 

* @param _J older The folder to append the message iq 
-/ 

protected void apperjdMessage(Message ^jnsg* String ^Jfclder) throws 
M cssagmgE* cept ion { 

// Gtt s Store ohjeel 

Store store rri„mail3ession .get Store ("i map"); 
stfjrt.cannec^m^strHost, m_strUscr, m__strPasswcrd); 
// Open folder (or create it if iE doesn't exist) 
Folder d folder = s tore. geiFo!dcF(„ folder): 

if (Jdfolder.exists ( )) dfoider.create(Fo]der.H01X>S„MESSAGES); 
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APPENDIX I-contimied 



GRAPHICS DATA CAPTURE & SENDING MODULE 



Message[ ] msgs* { _,ansg }; 
df olde r^ppendMessages( msgs); 
dfoldeT.clQse(fals&); 
sLOf enclose ( }; 

} 

} 



I claim: 

1. An electronic messaging system comprising: 

(a) a server component operable on a server computer on 
a network with an email host server for receiving an 
email message sent from a user and storing it for 
retrieval by a user to whom it is addressed^ 

(b) a remote client computer coonectable to the server 
computer through an online data connection to the 
network, and an email client software operable on the 20 
remote client computer for setting up an email client 
interface for the user to set up and send email to a 
recipient via the email host server on the server com- 
puter; and 

(c) a client coroponeot operable with the email client on 25 
the client computer connected to the network for setting 
up a graphical data capture area in the client computers 
email client interface, said client component also 
including a graphical input device which is operatively 
coupled to the graphical data capture area set up in the 30 
email client interface for allowing the user to enter 
handwritten or handdrawn input through the graphical 
input device, and for capturing the handwritten or 
handdrawn input as graphical data through the email 
client and sending it via the network to the server 35 
component for handling as an email message. 

2. An electronic messaging system according to claim 1, 
wherein the client component is operable for setting up a 
graphical data viewing area in the client computer's email 
client interface for viewing a handwritten or handdrawn 40 
email message received from the email host server of the 
server computer, 

3. An electronic messaging system according to claim 1, 
wherein the client component is a Java applet downloadable 

to the client computer's email client interface through a 45 
standard web browser on the client computer. 

4. An electronic messaging system according to claim 1, 
wherein the client component is a Java applet installed in the 
client computer's email client interface in a standard web 
browser on the client computer. so 

5. An electronic messaging sysiem according io claim 1, 
wherein the client component captures the graphical data as 
pixel data and sends it with the email message to the server 
component, and the server component encodes the pixel data 
and formats il as a graphics file for attachment to the email 55 
message. 

6. An electronic messaging system according to claim 5, 
wherein the server component is a handwriting Java server 
operating on the server computer and sends the email 
message with pixel data to a client computer having a similar 60 
client component for viewing the pixel data as a correspond- 
ing handwritten or handdrawn Image. 

7. An electronic messaging system according to claim 5 f 
wherein the server componem is a handwriting Java server 
operating on the server computer and converts the pixel data 65 
to a graphics file that is attached to the email message and 
sends it to an external SMTP gateway or Internet mail server. 



8. An electronic messaging system according to claim l r 
wherein the client component captures the graphical data 
and converts it to a graphics file that is sent with the email 
message to the server component* and the server component 
handles the email message as standard email with an 
attached graphics file. 

9. An electronic messaging system according to claim %, 
wherein the server component is a handwriting Java server 
operating on the server computer and sends the email 
message with attached graphics file to a client computer 
having a similar client component for viewing the graphics 
file as a corresponding handwritten or handdrawn image, 

10. An electronic messaging system according to claim 8, 
wherein the server component is a handwriting Java server 
operating on the server computer and sends the email 
message with attached graphics file to an external SMTP 
gateway or Internet mail server. 

11. An electronic messaging system according to claim 1, 
wherein the client component captures the graphical data as 
pixel data and encodes it as a message for sending to the 
server component, and the server component formats the 
message as an email message with an attached graphics file. 

12. An electronic messaging system according to claim 1, 
wherein the client component captures the graphical data as 
pixel data and sends il with the email message to the server 
component^ and the server component sends the email 
message wiih the pixel data to a client computer having a 
similar client component for viewing the pixel data as a 
corresponding handwritten or handdrawn image. 

13. An electronic messaging method comprising: 

(a) providing a graphical data capture area in an email 
client interface operable on a client computer having an 
online connection to a network; 

(b) providing a graphical input device operatively coupled 
to the graphical data capture area set up in the email 
client interface; 

(c) composing an handwritten or handdrawn email mes- 
sage in the graphical data capture area through the 
graphical input device^ and capturing the handwritten 
or handdrawn input as graphical data through the email 
client and sending it as an email message via the 
oelwork to a server component operable on a server 
computer; and 

(d) receiving the email message via the server component 
and storing it for retrieval by a user to whom il is 
addressed. 

14. An electronic messaging device comprising: 

a handwriting messaging component operable in an email 
client interface of a computer connected on a network, 
wherein said handwriting messaging component sets 
up a graphical data capture area in the email client 
interface into which a user can enter handwritten or 
handdrawn input, 

a graphical input device which is operatively coupled to 
the graphical data capture area set up in the email client 
interface, and 
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wherein said handwriting messaging component captures 
the handwritten or banddrawn input as graphical data 
and sends it as an email message on the network. 

15. An electronic messaging device according to claim 14, 
wherein the handwriting messaging component converts the s 
graphical data lo a graphics file that is aLtached to the email 
message . 

16. An electronic messaging device according to claim 14, 
wherein the handwriting messaging component formats the 
graphical data as pixel data and send it with the email io 
message. 

17. An electronic messaging device according to claim 14, 
wherein the handwriting messaging component is operable 
for setting up a graphical data viewing area for viewing 
graphical data sent with an email message as a correspond- 15 
ing graphical image. 

IS, An electronic messaging device according to claim 14, 
wherein the handwriting messaging component is operable 
on a personal digital assistant or palm-top device for receiv- 
ing graphical email via a wireless connection on the network 20 
and viewing the graphical data sent with an email message 
as a corresponding graphical image. 
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19. An electronic messaging device according to claim 14, 
wherein the handwriting messaging component sets up the 
graphical data capture area through a Java applet operable 
with an email client installed on the device, 

20, A method of electronic messaging comprising: 
providing a handwriting messaging component operable 

with an email client interface on a device connected to 
a network; 

setting up via the handwriting messaging component a 
graphical data capture area in ifae email client interface 
into which a user can enter handwritten or banddrawn 
input through a suitable graphical input device; 

providing a graphical input device which is operatively 
coupled to the graphical data capture area set up in the 
email client interface; and 

capturing the handwritten or handdrawn input as graphi- 
cal data through the email client and sending it as an 
email message on the network. 
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INFORMATION MANAGEMENT NETWORK 
FOR AUTOMATED DELIVERY OF ALARM 
NOTIFICATIONS AND OTHER 
INFORMATION 

PRIORITY 

This application claims priority from U.S. Provisional 
Applications Ser. No. 60/166,585, fikd Nov. 19, 1999, and 
Ser. No- 60/232,340, filed Sep. 14, 2000, and incorporates 
both by reference herein as though fully set forth herein. 

FIELD OF THE INVENTION 

This invention relates generally to security and monitor- 
ing systems for both residential as well as business and 
industrial use. It relates more particularly to security and 
monitoring systems that operate over wired or wireless 
networks. Eve a more particularly, it relates to security and 
information systems that use condition sensors connected by 
a network that facilitates remote monitoring, notification, 
and interaction. 

BACKGROUND OF THE INVENTION 

Existing premises security monitoring systems are usually 
connected to central monitoring stations via the public 
switched telephone network (PSTN) or a by a commercial 
wireless network. In the event of a system alert, current 
monitoring center procedures provide the customer with an 
alarm verification call, notification to the local police or fire 
authorities, and notification to a number of designated 
contact numbers, Although only 20% of the households in 
this country have monitored security systems, false -alarm 
police dispatches account for 98% of police dispatches 
nationwide. Such false alarm events typically cost munici- 
palities nationwide over SL5 billion per year. As a result of 
the high incidence of false alarms plaguing the industry, il is 
not uncommon for the police to take as long as an hour to 
reach the premises where an alarm has been activated. 

Further, when an alarm system is violated, the siren only 
sounds for a period of up to five minutes. Should the 
homeowner return to the premises before the police arrive 
and after the alarm ceases, the safely of that individual is 
seriously compromised. 

In the residential security system industry today* upon the 
receipt of an alarm transmission from a security or premises 
monitoring system, the dispatcher of the central station 
monitoring facility calls the premises to verify whether the 
emergency event is valid. If there is no answer or if it is 
otherwise deemed necessary, the dispatcher notifies the 
appropriate authority for emergency dispatch. At the time of 
emergency notification, the dispatcher at the central station 
monitoring facility is limited to the information transmitted 
from the base unit in the premises. The dispatcher does not 
have access to real-time information about the situation tha£ 
could influence his decision as to whether to notify the 
emergency authority. 

Furthermore, the calls made to the customer contacts after 
the authorities are dispatched are most typically not given 
priority by the central station monitoring facilities and are 
only made to the customer contacts when emergency calls 
and dispatches for other customers are not being made. 
Therefore, it is not uncommon for the comacts listed in the 
customer file to be notified about the alarm so long after the 
incident that notification is useless- 

When the central station monitoring facility calls the 
premises to verify the alarm event, if the event notification 
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is not cancelled, the dispatcher immediately notifies the 
emergency authorities for dispatch to the premises in ques- 
tion. If the homeowner is not at home at the time of the alarm 
event, the homeowner's knowledge of the premises, hard* 
ware and authorized users is not available to influence or 
control the action taken by the central station monitoring 
facility at the time of alarm signal transmission. And, it is 
only after the emergency authorities have been dispatched 
that the dispatcher of the central station monitoring facility 
attempts to notify the other contacts listed in the customer's 
file. 

Current systems also allow customers limited or no 
opportunities to alter contact numbers in their profiles or to 
be contacted via the growing variety of communication 
devices available to the public {e.g., fax, e-mail, pager, 
Personal Digital Assistant (PDA), text messaging device). It 
is therefore generally uncommon for the contact cumbers 
stored in Ihe customer's contact list to be up-to-date due to 
the cumbersome process required to update a contact list. 

These factors seriously compromise the safety of the 
owner of the premises, who, if not on premises at the time 
of the alarm event, may not receive information about the 
alarm notification prior to entering the premises while an 
intruder is still present. The above factors also contribute to 
the high incidence of false alarm dispatches in this country. 
If the owner of the premises is not on the premises at the 
lime of the alarm event, the owner is not able to direct the 
central station monitoring facility whether to cancel or 
continue with authority dispatch. 

The current call flow process from a security or premises 
monitoring system direct to a Central Monitoring Station, 
which calls the premises for verification and then notifies the 
authority for emergency dispatch, is an inefficient premises 
monitoring solution. This call flow configuration also has 
adverse cost and safety implications for the system owner* 
central station monitoring facilities, authorities, and cities 
alike. 

It is therefore an object of the invention to provide an 
improved system for monitoring premises security and other 
conditions. It is a primary object of this invention to provide 
a system that transmits interactive notifications about pre- 
mises event and alert information in the order and manner 
determined by the customer within the customer profile to 
any wired or wireless communication device. It is yet a 
further object of this invention to receive transmissions of 
alarm notifications regarding changes in the status of any 
one of a number of sensors or parameters in a security or 
premises monitoring system at a remote Information Man- 
agement Network via the Public Switched Telephone 
Network , Wireless Commercial Network, cable network or 
other commercial network. 

It is another object of the present invention that the 
customer be able to remotely and securely access the Infor- 
mation Management Network via the Internet or telephone 
to modify and review the information in his Customer 
Profile and Event Log within the Information Management 
Network^ using a secure web or telephone interface, to easily 
and securely maintain and update contact lists and notifica- 
tion preference points, schedule times for certain informa- 
tion notifications, update call flow sequences, access per- 
sonal account information, review detailed alarm history, 
review results of notifications made to each of the delineated 
devices,, review billing information, schedule non-alarm 
event notifications and update and review other alarm signal 
and hardware related information. It is another object of the 
invention that the Information Management Network initiate 
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periodic interactive notifications to customers to encourage 
them to update their Customer Profile by entering ihe correct 
digital or voice recognized pass code. 

Ii is yet a further object of the invention that the customer 
be able to determine the order in which contacts will receive 
the event transmission and have the opportunity to cancel 
said event transmission prior to said transmission being sent 
to the central station monitoring facility or private guard 
service for authority dispatch. It is another object of the 
present invention that an authorized reeipiem of an event 
notification can cancel the transmission of the notification to 
the subsequent contacts in the notification sequence or a 
central station by entering the correct digital or voice 
recognized pass code. It is yei another object of this inven- 
tion that a centra] station monitoring facility use the Infor- 
mation Management Network to contact customer devices 
listed in the Customer Profile concurrently or following the 
dispatcher's verification call to the home, to allow an 
authorized individual, remote from ihe premises, to cancel 
the alarm noUfication prior to dispatch of the authorities. It 
is still another object of the invention that the recipient of a 
notificaiton cail be able io be transferred or conference^ with 
Ihe emergency authority through a digital or voice request. 
It is another object of the invention that the receipt of 
information by ihe recipient can be confirmed and a record 
kept in the event log database of the Information Manage- 
ment Network for retrieval and review at a later date by an 
authorized individual. It is another object of the invention 
that the Information Management Network complement or 
replace the functions of a central station monitoring facility. 

SUMMARY OF THE INVENTION 

The system of the current invention provides to users and 
central station monitoring facilities an efficient and afford- 
able event notification solution in which the call flow 
configuration of the invention is designed to enhance the 
safety and convenience of the customer and reduce the 
incidence of police, fire, or other emergency dispatches 
generated by false alarms. The invention comprises a secure 
interactive and remotely accessible Information Manage- 
ment Network (IMN} based routing system for alert, 
medical, and other emergency event information. The sys- 
tem delivers sequential interactive event notifications based 
on signals received from sensors at the monitored premises 
and sends them in text, voice, DTMF or digital, text 
messaging, or other formats to a plurality of remote wired 
and wireless devices, including cell phone, pager, email 3 
SMS, landHne phone, text messaging device, personal digi- 
tal assistant, and fax as appropriate. The IMN further deliv- 
ers such notifications to a pre -design a ted central station 
monitoring facility in security industry format. 

Hie hardware of the IMN is a combination of a plurality 
of modems, an alarm monitoring engine* at least one server 
containing customer information databases, a unified mes- 
saging platform, event logs, web and telephony interfaces, 
an interactive messaging server^ a Private Branch Exchange/ 
Interactive Voice Response (PBX/IVR) interface , and a 
telephone conferencing switching mechanism. This configu- 
ration translates the data received from a premises hardware 
uniL into a notification capable of being sent in voice or test 
format io any number of customer designated devices 
including telephones fax, email addresses, pager, Personal 
Digital Assistant (PDA), or text messaging device. The 
systems are redundant. 

The IMN routing system is domiciled at a secure inde- 
pendent hosting facility or at a secure central station mom- 
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toring facility. The system is able to receive event and alert 
information from any security or premises monitoring 
devices and sequentially transmit interactive notifications 
about the event and alert to wired and wireless communis 
s cations devices specified in the Customer's Profile within 
the IMN. Transmissions can be made in voice, text, DTMF, 
digital, text messaging or other formats to such devices as 
cell phone, pager^ email, fax, text message device and SMS, 
as well as in ContacL ID, SI A, or other security industry 

10 formats io an independent central station monitoring facility 
for them in turn to dispatch the authorities. 

The automated secure remote IMN has a novel interactive 
alarm notification call flow sequence that uses information 
stored in the Customer Profile within the database of the 

15 IMN to notify designated points of contact by making 
sequential interactive notifications to one or more persons or 
locations previously designated in the Customer Profile over 
one or more wired and wireless devices in text, voice, 
DTMS, text messaging or digital formats to notify them of 

20 an emergency event or a change in the status of any premises 
sensors. Delivery to any of the above destinations occurs in 
the order and manner specified in Ihe authorized user's 
Customer Profile within the IMN. 

For an alarm notification, the information conveyed can 

25 include the customer name, address, location of the security 
or premises hardware, phone number of the security or 
premises hardware, date, time, type and name of sensor, 
zone* local emergency authority phone number, arid other 
relevant personal or premises-related information. The IMN 

30 also allows for a two-way communication Interface with the 
security or premises hardware. 

The IMN, having automatically received an alert notifi- 
cation from the premises where the monitoring devices are 

^ 5 located, automatically accesses a data base, finds the par- 
ticular owner's profile, and then also automatically sends 
interactive alert messages to phones, faxes, email devices, 
pagers, hand-held computers and/or a manned monitoring 
center as previously specified by the owner. The use of tbe 

40 alarm system is electronically logged io the IMN so that it 
can be reviewed later. 

The system uses tbe information populated within the 
Customer Profile to instantly alert the customer and his 
contacts of the alarm event, for example, to warm them of 

45 an intruder on the premises or to alert them to another type 
of emergency event at the premises and enable them to make 
a decision as to whether the emergency authorities should be 
notified by the customer directly or through a central station 
monitoring facility or guard service, or the event notification 

50 should be cancelled. 

The user can securely access the IMN via the Internet or 
telephone to program or re -prog ram the user's customer 
profile, to include notification preference points, ordering of 
notifications, routing paths for different types of 

55 notifications, times for notification and other related infor- 
mation. This access is to a single universal access point. 
Receipt of information by the user can be confirmed and a 
record kept in the event log database of the IMN for retrieval 
at a later date by an authorized user. 

60 Tbe IMN also permits the user to modify the pre-existing 
premises alarm notification call flow sequence by allowing 
the user to direct and manage the alarm notification process. 
Event notifications from the IMN are interactive and made 
sequentially to the contacts designated in the Customer's 

65 Profile, allowing the recipient of the even! notification to 
determine the next action to be taken by the IMN in the call 
flow sequence. Authorized recipients are able to terminate or 
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redirect subsequent event notifications by entering the cor- 
rect pass codes digitally or through voice recognition tech- 
nology. 

Customers can select the number and ordering of contacts 
to be notified and queried prior to alarm event transmissions 5 
being sent to the central station monitoring facility for 
emergency authority dispatch. Customers can select to have 
a central station monitoring facility as part of the call flow 
sequence, or have notifications sent only to the contacts 
listed in their profile for those contacts to notify emergency 10 
authority for dispatch. Authorized users can access their 
Customer Profile via a pass code encrypted telephone or 
Internet interface, to change alarm system configuration, 
update their points of contact, establish the order in which 
contacts will be notified based on the type of alarm event and 15 
review emergency information any time they desired. Using 
the pass code accessible Internet and telephone interfaces, 
users can access information aboul their accounts, including 
billing information, contact points, pass code information 
and alarm history, The invention also provides for externally 20 
specified and changeable control of alarm system operation 
and borne automation devices via the IMN or from a remote 
telephone. Externally directed control of alarm system 
operation and home automation devices takes place via the 
INN, 25 

The ability to securely and easily update contact infor- 
mation at anytime and from anywhere allows the customer 
to be part of and closely manage the security notification call 
flow process and enhance his safety by directing alarm event ^ 
notifications to contact him on specified devices early on in 
the event notification process. This feature, coupled with the 
user's ability to cancel an alarm notification prior to its being 
sent to the central station monitoring facility, influences the 
call flow sequence of alarm event information and reduces ^ 
the incidence of false alarm dispatches. Authorized contact 
recipients are identified with user-determined pass codes, 
verified by a digital pin number or Voice Recognition pin 
number, prior to that person instructing the IMN as to the 
next step or steps of action to be taken in the call sequence. ^ 
Another important feature is the logging of event notifies- 4 
tion information into the database of the IMN so that the 
customer can review it at a later date. 

In this system users have direct, secure access to the 
monitoring network database via phone or the global com- 45 
puter network in order to review and change alarm system 
configuration, points of contact and emergency information 
any time they desire. Customers have access to securely 
manipulate their personal information within their Customer 
Profile over the telephone or through a web interface, 24 5Q 
hours a day. 

Customers can elect to have ceotral station momtoring 
facility back -up capability to be employed after one or more 
contacts listed in the Customer's Profile have been contacted 
and queried, and have failed to receive or respond correctly 55 
to the interrogation from the IMN. Customers can also elect 
not to have a central station monitoring facility as pari of the 
call flow sequence and have the notifications sem only to the 
contacts listed in their Customer Profile, In all notification 
calls, customers are provided the opportunity 10 be trans- 60 
ferred directly to the emergency authority for them to initiate 
a dispatch to the premises. 

In certain instances, customers can select to have a central 
station monitoring facility or guard service notified for 
police or emergency dispatch, after one or more of the 65 
contacts listed in the Customer Profile have received the 
information and have either failed to properly cancel the 



event notification or have proactively instructed the IMN to 
contact the central station monitoring facility or guard 
sendee for dispatch. At the same time, recipients of alarm 
and event notifications are provided the local police number, 
as well as the ability to be transferred or conferenced with 
the local police or emergency authority- 
Through the IMN* customers can also subscribe to receive 
notifications with content not related to the security or 
premises hardware. Such notifications include medication 
reminders* homeland security notifications and news events, 
transmitted at specific times, on specific dates, or under 
specific circumstances, and transmitted to a plurality of 
wired and wireless devices in text and voice formats as 
designated in the customer profile. 

BRIEF DESCRIPTION OF THE DRAWINGS 

1, FIG. 1 is a diagram of the communication flow estab- 
lished by the Information Management Network, 

2. FIG. 2 is a diagram of the communication established 
by the Information Management Network including the 
central station monitoring facility or private guard service, 
the police, or other emergency authority. 

3. FIG, 3 is a schematic diagram depicting the hardware 
components of the Information Management Network and 
the communications portals into and out of the Information 
Management Network, 

4, FIG. 4 is a flow diagram illustrating the work flow 
process within the Information Management Network. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

A Security or Premises Monitoring System has been 
previously described in the parent application, which has 
been incorporated by reference. The Security or Premises 
Monitoring System is connected by a communications 
circuit, which can be any of or a combination of elements 
selected from the public switched telephone network* a 
wireless network, digital subscriber line via modem, cable 
modem connected to 2 cable network, the internet, and any 
other communications network capable of transmitting dual 
tone multiple frequency tones or their equivalent. The Secu- 
rity or Premises Monitoring System connects on demand to 
the Information Monitoring Network (IMN) of this 
invention, described below. 

With respect to hardware, the IMN comprises at least a 
DTMF modem, an application interface, at least one server 
containing customer information databases, a unified mes- 
saging platform, an event log, a web interface, and a 
telephony interchange, such as a Private Branch Exchange/ 
Interactive Voice Response (PBX/IVR) interface. (See FfG. 
3). The at Jeast one server comprises a server type computer 
the nature and configuration of which is well known to those 
skilled in the art. Those skilled in the art wilt also recognize 
that the network of this invention can be implemented with 
a variety of computing and communications hardware dif- 
fering from those explicitly disclosed in this application but 
well known to those skilled in the art. 

The hardware and software configuration translates tbe 
DTMF tones received from the Security or Premises Moni- 
toring System into a message capable of being seat in voice 
or text format. As the following will describe, the IMN 
enables sending the message to any number of customer 
designated devices including telephone, fax, email 
addresses* pager, or Personal Digital Assistant (PDA) such 
as a PALM PILOT 
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Referring to FIG. 1, alarm or event information is sent 
from the Security or Premises Monitoring System 1 to the 
remote Information Management Network 2 via any type of 
communication channel. The system retrieves user informa- 
tion and alert notification addresses (including but not 5 
limited to phone numbers, fax numbers email addresses, 
pager numbers, and Persona! Digital Assistant device 
addresses) from the customer database and, as described in 
more detail below, forwards the alarm notification or medi- 
cal information to the designated points of contact, simul- 10 
taneously or sequentially. For an alarm notification, the 
information conveyed includes the customer name^ location 
of the base unit, phone number of base unit, date, time, type 
of sensor and zone. 

Interactive notifications are then sent from the Inforraa- is 
tion Management Network to the contacts listed in the 
Customer Profile 17 (shown in FIG. 3) via at least one 
communication device, including cell phone, pager, email, 
SMS, laadikte phone, fax or text messaging device. Contact 
recipients of the interactive alert notifications are provided 2 o 
the option to cancel the event notification by providing a 
correct pass code using digital entry or voice recognition 
technology; send the alert notification to the next contact io 
the Customer Profile 17, or be transferred to or conferenced 
with the local emergency authority. There is no central 2 5 
station monitoring facility associated with the call flow 
sequence of FIG- 1. 

Referring to FIG. 2, alarm or evem information is sent 
from the Security or Premises Monitoring System 1 to the 
remote Information Management Network 2 via any com- 30 
munication channel including the Public Switched Tele- 
phone Network, the Internet, Cable or a Wireless Network. 
Interactive notifications are then sent to the contacts by the 
Information Management Network listed in the Customer 
Profile 17 (shown in FIG. 3) via any number of communi- 35 
cation devices including cell phone, pager, email* SMS, 
kndlioe phone, fax or text messaging device. Contact recipi- 
ents of the interactive alert notification are provided the 
option to: cancel the event notification by providing the 
correct pass code using digital or voice recognition technol- 40 
ogy; send the alert notification to the next contact in the 
Customer Profile 17; send the alert notification to the central 
station monitoring facility. In this configuration, the central 
monitoring station is generally responsible for police and 
emergency authority notification for dispatch, but option aDy 45 
the responder can be transferred to or conferenced with the 
local emergency authority- 
Referring to FIG, 3 , information sent from the Security or 
Premises Monitoring System 1 to the Information Manage- 
ment Network 2 enters the Information Management Net- so 
work 2 through the Telephony Server 11, Cable Modem 12 
or IP Server 34. Alarm information then flows through the 
Alarm Monitoring Engine 15 to the Database Server 16. 
Information regarding the specific account is stored in the 
Customer Profile 17 within the Database Server 16 that 55 
provides the work flow process for each alarm event. All 
alarm notification events are sent by the Interactive Mes- 
saging Server 18 to the customer contacts via landline 
phone, cell phone, text messaging device, pager, email, fax 
or SMS, The Interactive Messaging Server 18 can ioterro- 60 
gate the contact recipient of the alarm notification for 
information and institute the appropriate work Sow process 
based on the response of that contact. The results of all work 
flow processes are stored the Event Log 19 and can be 
reviewed by authorized individuals through the Telephony 65 
Interface into the Telephony Server 11 or the Web Interface 
through the Web Server 20, During a notification, customers 



are provided the option to be connected to the police phone 
number listed in their Customer Profile 17 within the Data- 
base Server 16. This connection is made through the Tele- 
phone Conference Switching Mechanism 21* Alarm notifi- 
cations associated with central station monitored accounts 
are transmitted from the Database Server 16 to the central 
station monitoring facility via the Interactive Messaging 
Server IS following the call flow sequence designated in the 
Customer Profile 17, Access to the Customer Profile 17 and 
changes to said Customer Profile 17 are made through the 
Telephony Server 11, Customer Service Receiver 22 and 
Web Server 20 into the Information Management Network 

Referring to FIG. 4 t the call flow processes are detailed 
for an alarm event When the incoming signal is received by 
the Information Management Network 2, the signal enters 
the Alarm Monitoring Engine 15 and is immediately logged 
into the Event Log 19 within the Database Server 16. The 
alarm notification string is parsed to determine information 
about the account. Using the customer identification 
number, the Customer Profile 17 within the Database Server 
16 is queried for the alarm type and customer account 
information for the work flow processes. 

For a central station monitored account, there are different 
workflows associated with non-critical, critical panic, and 
fire events. In the event of a non-critical alarm, which 
represents a low battery event, AC Power loss or other 
non-crittcal event, the alarm event information is sent by the 
Notification Engine 23 within the Interactive Messaging 
Server IB to the customer's non-critical contact on the 
device specified in the Customer's Profile 17, The results of 
this notification are stored in the Event Log 19 within the 
Database Server 16. In the event of a critical alarm, the 
information is sent to the customer's first contact using the 
Notification Engine 23 within the Interactive Messaging 
Server 18. The contact is given the option to cancel the alarm 
or send the signal to the central station monitoring facility S 
for dispatch, 

If the contact request 's that the central station monitoring 
facility 8 be notified for the dispatch of the authorities, the 
Notification Engine within the Interactive Messaging Server 
IS sends the alarm transmission to the central monitoring 
station 8 for authority dispatch and the results of the work 
flow process are stored in the Event Log 19. All other 
contacts listed in the Customer's Profile 17 are then notified 
that alarm event notification was sent to the central station 
monitoring facility S, 

If the alarm notification information is sent to a device 
where the contact chooses to cancel the alarm event, the 
customer's notification cancel code is requested. If the 
correct alarm notification cancel code is entered, the alarm 
notification event and work Sow process are cancelled and 
the information of the work flow process is stored in the 
Event Log 19. 

If the incorrect alarm notification cancel code is entered, 
the customer is requested to re-enter the code. If an invalid 
alarm notification cancel code is entered second time, or no 
code is entered, the work flow process moves 10 the next 
contact listed in the Customer's Profile 17 and the notifica- 
tion process is repeated. When the second contact is notified, 
if there is no answer, an invalid cancellation code is entered 
or the contact selects to have the central station monitoring 
facility $ notified, the alarm event is sent to the central 
station monitoring facility S for authority dispatch and the 
information is stored in the Event Log 1 9. In any case where 
a valid alarm notification cancel code is entered, the noti- 
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fication event and the workflow process are cancelled, and 
the information regarding the cancellation of the alarm event 
notification is stored ho tbe Event Log 19. In any case where 
the central staiion monitoring facility $ is notified for 
dispatch, all remaining contacts are notified that the alarm 
event was sent to the central staiion monitoring facility 8 and 
the information is then stored in the Event Log 19. When an 
alarm notification is sent, if the notification is unable to be 
delivered by the Information Management Network 2, if the 
line is busy or there is no answer by the first contact listed 
in the Customer Profile 17, the workflow process moves to 
the next contact listed in the Customer Profile 17. 

If the first contact is answered by a voice mail or answer* 
ing machine, the Notification Engine 23 within the Interac- 
tive Messaging Server 18 recognizes that it is not a live 
person, ieaves a message and the work tlow process moves 
to the next contact listed in the Customer's Profile 17, If the 
next contac! is not answered, is answered by a voice mail or 
answering machine, or is answered and the correct alarm 
notification cancel code is not entered, the Notification 
Engine 23 within the Interactive Messaging Server IS leaves 
a message where applicable and the alarm event notification 
is sen! to the central station monitoring facility S and the 
remaining contacts listed in the Customer Profile 17 are 
notified that alarm even! was sem to the central station 
monitoring facility 8, This information is then stored in the 
Event Log 19 within the Database ServeF 16. 

In the event of a fire or panic alarm event, the information 
is sent directly to the central station monitoring facility S and 
all of the customer contacts listed in the Customer Profile 17 
are notified of the alarm event, The information is stored in 
the Event Log 19. There are no cancellation privileges 
associated with these events. 

For an account that does not have central station 3; 
monitoring, there are different workflows associated with 
non-critical, critical, panic, and fire events. In the event of a 
noncritical alarm, which represents a low battery event, AC 
Power loss, or other non-critical event, the information is 
sent to the customer's non-critical contact on the specified 4G 
device, using the Notification Engine 23 within the Interac- 
tive Messaging Server IS. The results of this notification are 
stored in the Event Log 19 within the Database 16. 

In the event of a critical alarm, me information is sent to 
the customer's first contact using the Notification Engine 45 
within the Interactive Messaging Server 18. The contact is 
given the option to cancel the alarm event or send the signal 
to the next contact listed in the Customer's Profile 17. 

If the contact chooses to cancel ine alarm event, the 
customer's notification cancel code is requested. If the 50 
correct alarm notification cancel code is entered, the alarm 
notification event and work Sow process are cancelled and 
the resulls of the work flow process are stored in the Event 
Log 19, If the incorrect alarm notification cancel code is 
entered, the customer is requested to re-enter the alarm 55 
notification cancel code. If an invalid alarm notification 
cancel code is entered a second time, or no alarm cancella- 
tion code is entered,, the work flow process moves to the next 
contact listed m the Customer^ Profile 17 and the process is 
repeated. This work flow process will continue through all of 60 
the customer contacts until the alarm event is cancelled 
using the correct alarm notification cancel code. With each 
nofification, the contact is given the information about the 
alarm event, including the name, address and system zone 
activatedj as well as the police phone number to contact in 65 
the event of an emergency. During the process, the contact 
is given the option to have the notification sent to the next 



contact listed in the Customer Profile 17; given the option to 
cancel the notification; or be connected directly to the police 
phone number listed in bis Customer Profile 17. In any case 
when a valid alarm notification cancel code is entered,, the 
notification event and the workflow process are cancelled 
and the information is stored in the Event Log 19 within the 
Database Server 16. When an alarm notification is sent, if 
the line is busy or there is no answer by the first contact 
listed in the Customer Profile 17, the workflow process 
1 moves to the next contact listed in the Customer's Profile 17 
to continue the work flow process. 

In the same event, if the noti fication is answered by a 
voice mail or answering machine, the Notification Engine 18 
recognizes that it is not a live person, leaves a message and 
the work Sow process moves to the next contact listed in the 
Customer's Profile 17, If the next contact is busy, not 
answered, answered by a voice mail or answering machine, 
or answered and the correct alarm notification cancel code is 
not entered, the Notification Engine IS, leaves a message 
where applicable and moves to the next contact listed in the 
Customer's Profile 17, This process continues through all of 
the contacts listed in the Customer's Profile 17 until the 
correct alarm notification cancel code is entered to cancel 
the work Sow process. 

After the work flow process has attempted contact with all 
devices listed in the Customer's Profile 17 s the Notification 
Engine 23 within the Interactive Messaging server IS will 
try to send the alarm notification to those devices that were 
busy or where there was no answer to attempt to deliver the 
alarm event notification information. 

In the event of a fire or panic alarm event, all of the 
customer contacts listed in the Customer Profile 17 are 
notified of the event and the results of the notification are 
stored in the Event Log 19 within the Database Server 16. 
There are no cancellation privileges associated with these 
events. 

Confirmation that the alarm notification has been success- 
fully transmitted to the customer's designated device(s) is 
housed in the event log and also in the Security or Premises 
Monitoring System. In a preferred embodiment, the 1MN 
allows for a two-way communication interface with the base 
unit. In this way, the present invention allows for remote 
activation or resetting of the alarm and other devices id the 
home for security and home automation purposes, through 
the initiation of a phone call or global computer network 
transmission to the IMN. The IMN also allows the customer 
to preprogram alarm and home automation functions to 
initiate specific processes at specified times of the day. 

The Information Management Network 2 can be pro- 
grammed to forward certain alarm event transmissions 
directly to the central station monitoring facility 8 while 
other event transmissions are sent to the central station 
monitoring facility S only after the first, second, third or 
fourth transmission to the contacts listed in the Customer 
Profile 17, 

Referring to FIG. 3 again, the account information in the 
Customer Profile 17 within the information Management 
Network 2 can be populated by the customer or other 
authorized individual via a secure web interface on the Web 
Server 20 or via a secure telephone interface using the 
Telephony Server 11, To access their Customer Profile 17, 
customers are required to provide their persona] user name 
and a unique personal pass code. Through these interfaces, 
authorized individuals can customize their personal account 
information to add, delete or modify tbeir pre -designated 
contacts and designate the order of alarm event information 
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transmissions to their contacts, modify their home address* 
phone lumber, police contact number, and billing informa- 
tion. Any change made to data within the Customer Profile 
17 is automatically sent via PSTN or Internet interface to the 
central station monitoring facility & to update the customer's 
account information on a real time basis, This transfer of 
information applies only to those customers subscribing to 
central station monitoring services, which services serve as 
a complement to Lhe alarm notification call flow process 
made by the Inform ation Management Network 2, 
What is claimed is: 

1. An information management network system for rout- 
ing information to one or more recipient said network 
system comprising: 

a) means for receiving information from a monitoring 
system; 

b) one or more user profiles, each of the one or more user 
profiles comprising one or more specified notification 
contact data entries asd a specified notification contact 
flow sequence; 2( 

c) means for selecting a single user profile corresponding 
to the monitoring system and for retrieving the selected 
single iiser profile; 

d) means for extracting from the selected single user 
profile the one or more specified notification contact 2f 
data entries and the specified notification contact flow 
sequence; 

e) means for identifying from each of the one or more 
notification contact data entries one or more commu- . . 

3C 

nicalion receiving devices and for each such device a 
device -specific format, each of said communication 
receiving devices being configured both to receive 
messages in device-specific formats and to transmit a 
response message back to the information monitoring 35 
network; 

f) means for generating from the information received 
from the monitoring system and from each of the one 
or more notification contact data entries one or more 
interactive event notifications, each in a device -specific 4Q 
format corresponding to each of the one or more 
configured communication receiving devices; 

g) means for transmitting said one or more interactive 
event notifications in device -specific formats to each of 
the one or more configured communication receiving 4S 
devices either sequentially or simultaneously according 

lo the specified notification contact flow sequence; 

h) means for receiving from each of the one or more 
communication receiving devices, either sequentially 

or simultaneously according to the specified notifica- 50 
tion contact flow sequence, additional information or 
instructions containing specified subsequent actions to 
be taken by the network; 

i) means for altering the specified notification contact flow 
sequence according to lhe specified subsequent actions 55 
contained in the additional information or instructions 
received from each of the one or more configured 
communication receiving devices; and 

j) means for carrying out subsequent actions to be taken 
by the network according to the altered specified ooti- 60 
Sea tion contact flow sequence. 

2. The information management network system of claim 
1 wherein the monitoring system is a premises monitoring 
system. 

3. The information management network system of claim 65 
1 wherein me information received from a monitoring 
system comprises an alarm or event notification. 



4. The information management network system of claim 
2 wherein the premises monitoring system is located 
remotely from the network system at a remote premises. 

5. The information management network system of claim 
1 wherein the user is a customer of an entity maintaining the 
information management network system. 

6. The information management network system of claim 
1 additiooally comprising a premises monitoring system. 

7- The information management network system of claim 
1 additionally comprising 

a) one or more event logs corresponding to the one or 
more user profiles; and 

b) means for storing in the event log information com- 
prising the information received from the monitoring 
system and information regarding the one or more 
interactive event notifications sent by the network, 

8. The information management network system of claim 
7 additionally comprising means for the user to access and 
retrieve information stored in the event log, 

9. Hie information management network system of claim 
1 additionally comprising; 

a) means for enabling a user to remotely access the user's 
user profile and the corresponding even! log; and 

b) means for enabling the user, after having accessed the 
user's profile, to change the specified notification con- 
tact data entries and the specified notification contact 
flow sequence, thereby changing the order and manner 
in which event notifications are transmitted to the one 
or more configured communication receiving devices. 

10. The information management network system of 
claim 9 wherein the means for enabling a user to remotely 
access the user's user profile and the corresponding event 
log is either a telephone interface or an internet interface, 

11. The information management network system of 
claim 1 in which the one or more configured communication 
receiving devices to which interactive event notifications are 
directed are selected from the group: cell phone, e-mail, 
pager, land line phone, text messaging device^ short mes- 
saging system, facsimile machine, and all combinations 
thereof. 

12. The information management network system of 
claim 1 in which at least one of the one or more configured 
communication receiving devices is located at a staffed 
central station, and in which the device -specific format is a 
security industry data format, whereby the staffed central 
station is enabled to notify emergency authorities of the 
information received from the monitoring system. 

13. The information management network system of 
claim 12 in which the staffed central station is enabled to 
send notification of an event to the user's home and to ro^te 
a notification to the user at another location either concur- 
rently with the notification to the home or sequentially. 

14. The information management network system of 
claim 1 additionally comprising a means for voice telephone 
conferencing. 

15. The information management network system of 
claim 1 additionally comprising means for sending out 
messages to users reminding them to update their user 
profiles. 

16. The information management network system of 
claim 15 wherein the means for sending out messages to 
users comprises via email providing a link whereby to the 
web site for users can update their user profiles. 

17. The information management network system of 
claim 15 wherein the means for sending out messages to 
users comprises a telephone interface^ whereby lhe user is 
enabled to use the telephone key pad to update the user's 
user profile. 
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18, A method of routing information to one or more 
recipients comprising the steps of: 

a) receiving information from a monitoring system; 

b) storing one or more user profiles^ each of the one or 
more user profiles comprising one or more specified 5 
notification contact data entries and a specified notifi- 
cation contact flow sequence; 

c) selecting a smgle user profile corresponding to the 
monitoring system 

d) retrieving the selected single user profile; 

e) extracting from the selected single user profile the one 
or more specified notification contact data entries and 
the specified notification contact flow sequence; 

f) identifying from each of the one or more notification 35 
contact data entries one or more communication receiv- 
ing devices and for each such device a device-specific 
format, each of said communication receiving devices 
being configured both to receive messages in device- 
specific formats and to transmit a response message 20 
back to the information monitoring network; 

g) generating from the information received from the 
monitoring system and from each of the one or more 
notification contact data entries one or more interactive 
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event notifications, each in a device-specific format 
correspoading to each of the one or more configured 
communication receiving devices; 

h) transmitting said one or more interactive event notifi- 
cations in device-specific formats to each of the one or 
more configured communication receiving devices 
either sequentially or simultaneously according to the 
specified notiiicatioo. contact flow sequence; 

i) receiving from each of the one or more communication 
receiving devices, either sequentially or simultaneously 
according to the specified notification contact flow 
sequence, additional information or instructions con- 
taining specified subsequent actions to be taken by the 
network; 

j) altering the specified notification contact flow sequence 
according to the specified subsequent actions contained 
in the additional information or instructions received 
from each of the one or more configured communica- 
tion receiving devices; and 
carrying out subsequent actions to be taken by the network 
according to the altered specified notification contact flow 
sequence. 



